Re: [PATCH 1/4] Make gdb_dirbuf local to functions

[Pedro Alves <palves@redhat.com>]

On 09/13/2017 11:46 PM, Sergio Durigan Junior wrote:
>> > Ah, that BUFSIZ.  That's the FILE* stream buffer size [1], so I don't
>> > see it makes sense to use it for paths over PATH_MAX.  It happens to be
>> > greater that 1024 on your system, but that's not guaranteed, no?
>> >
>> > [1] - http://pubs.opengroup.org/onlinepubs/9699919799/functions/setbuf.html
>> >       http://pubs.opengroup.org/onlinepubs/009695399/basedefs/stdio.h.html
> AFAIK that's not a guarantee, indeed.  Although "1024" is also a very
> low value for path names on some systems (for example, here PATH_MAX is
> defined as 4096), we already had this problem before.

Yes, but at least 1024 was stable and usually good enough.

>>> For reproducibility reasons I didn't want to use PATH_MAX.
>>
>> I don't understand this.  Can you expand?  What's not reproducible
>> about PATH_MAX?  How's that different from BUFSIZ?
>>
>>>> As an extension, on GNU/Linux, you can call 'getcwd (NULL, 0)' and
>>>> that returns a heap-allocated buffer of the necessary size.  Can we
>>>> rely on gnulib to implement that behavior everywhere?  Since
>>>> it seems like we're xstrdup'ing the dir anyway, that likely would
>>>> simplify things, and remove one arbitrary hardcoded limit, while
>>>> at it.
>>>
>>> That's true, and it's better when you consider reproducible builds as
>>> well.
>>
>> /me confused about that.
>>
>>>
>>> According to gnulib:
>>>
>>>   https://www.gnu.org/software/gnulib/manual/html_node/getcwd.html
>>>
>>> It is better to rely on this better version of getcwd.
>>
>> Alright.  This makes the above moot, though I'd still like to
>> understand the reproducibility argument, since I suspect that
>> may come back in other cases.
> 
> Well, maybe this is more a question of portability than reproducibility,
> but I mentioned the latter because I remember doing some fixes in some
> Debian packages that were failing the reproducible tests due to the
> presence of PATH_MAX.  They were actually failing to build on certain
> targets, but that can be seen as non-reproducibility as well.

I think that's stretching what reproducibility means too far,
and ends up being confusing.  AFAICT, it'd be like saying that a program
isn't reproducible because it uses "ptrace", because "ptrace" isn't portable.
Well, that "ptrace" call may be the whole point of the program.
If you can always build the program on environment A and end up with
the same binary, then the program is reproducible on environment A.
That does not mean that you should expect to build the program under some
environment B [e.g., different compiler version or different system
libraries, or different kernel, or different architecture, or ...] and
get the same binary as in environment A.

> 
> PATH_MAX is defined by POSIX but is not used by every system.  GNU/Hurd,
> for example, doesn't define it.  As usual with GNU programs the
> "correct" thing to do is not to rely on some hard-coded limit imposed by
> a header file, but rather to make use of the fact that glibc's getcwd
> offers the possibility to allocate the variable that holds the path
> according to its actual size.

Correct.  That's exactly why I thought of suggesting getcwd's extension.

> 
> There are some other problems with PATH_MAX, e.g., the fact that the
> maximum length of a pathname is really defined by the underlying
> filesystem you're using, so just using "4096" doesn't really reflect the
> reality.

Right, on GNU/Linux we can certainly have paths longer than that.

> 
> Again, maybe I should have said "portability issues", but I consider
> them reproducibility issues as well.

Alright, glad we cleared this up, and glad that it's all moot now.  :-)

Thanks,
Pedro Alves