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

[Pedro Alves <palves at redhat dot com>]

On 09/13/2017 11:03 PM, Sergio Durigan Junior wrote:
> On Wednesday, September 13 2017, Pedro Alves wrote:

>>> --- a/gdb/cli/cli-cmds.c
>>> +++ b/gdb/cli/cli-cmds.c
>>> @@ -380,6 +380,8 @@ quit_command (char *args, int from_tty)
>>>  static void
>>>  pwd_command (char *args, int from_tty)
>>>  {
>>> +  char gdb_dirbuf[BUFSIZ];
>>
>> I don't recall offhand -- what's "BUFSIZ"?  What defines it
>> and is it guaranteed to be the right size for getcwd?
> 
> BUFSIZ is defined by stdio.h, and is 8192 on my Fedora 25.  This is much
> greater than the previous "1024" that was being used before.  

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

> 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.

Thanks,
Pedro Alves