This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 1/4] Make gdb_dirbuf local to functions
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