Re: PATH_MAX and test-stat.h

[James Youngman]

On Sat, Jun 18, 2011 at 11:24 PM, Karl Berry <address@hidden> 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.