On Sat, Jun 18, 2011 at 11:24 PM, Karl Berry <k...@freefriends.org> wrote: > IMHO ... > > I suspect that the most useful thing we can do in gnulib is define > PATH_MAX to a non-constant expression on all platforms, > > And intentionally break loads of existing code? > I am highly doubtful that that is "useful"; "painful" sounds more > accurate :).
I much prefer obvious breakage, in which problem code simply fails to compile, to subtle breakage where your code compiles on all the systems you have access to but still has subtle problems. I suppose this is a personal preference. > I am aware that conceptually there is no PATH_MAX on Hurd and no > requirement for it to be a smallish constant, but it seems to me that > any real-world system has to define PATH_MAX as a reasonable constant > simply for compatibility with all the code that has been written with > that assumption over the last 30+ years. Yes. This will be the commercial vendors' position, certainly. Breaking your customers' build makes your customers irritated, and even a little of that causes sales to go elsewhere. A defence that you're doing it for your customer's (and their customers') own good doesn't help a lot. This is also why we still have broken interfaces offered all over the place, like atoi and gets. I spent a while writing safety-critical code. This made me very intolerant of situation where the computer can detect a problem with the code but doesn't, in the name of the programmer's convenience. Those kind of choices always came back to bite me. Eventually I found that for this kind of system, I was best served by library interface designs in which it's either impossible to use them incorrectly, or that something goes wrong every single time (as opposed to rarely or worse, invisibly) when the code is wrong. Perhaps the habits I learned in this process, while still helpful for me in other fields, aren't really practical in all use cases. For example, not everybody wants to pay for more correctness by accepting less convenience. Please forgive me if I sound a bit dogmatic. > Programmers who want to worry about it are free to do so > (and in GNU we *should* worry about it), but let's not impose it on > everyone. I tend to assume that the intended audience for gnulib is maintainers of GNU packages, but perhaps I'm a little too narrow in my view there. James.
