[PATCH 06/18] posix: Remove glob GET_LOGIN_NAME_MAX usage

Paul Eggert eggert@cs.ucla.edu
Sat Sep 2 22:50:00 GMT 2017


On 08/11/2017 07:50 AM, Adhemerval Zanella wrote:

> There is no actual login to resize the buffer in case of the resizing
> the buffer in case of ERANGE, so a static buffer using glibc default
> LOGIN_NAME_MAX is suffice.

Although I had trouble parsing that, I think you're saying that because 
the current glob.c goes awry when sysconf (_SC_LOGIN_NAME_MAX) < 0, it's 
OK if we change glob.c to insist on a fixed-size limit of 255 bytes on 
user name length so that glob continues to mishandle (presumably 
mostly-theoretical) environments with longer user names. But that's not 
the GNU style, which is to avoid arbitrary limits. Instead, let's fix 
glob.c so that it doesn't need to know the user name length limit. 
Obviously glob should use heap allocation for anything large, which 
suggests that it should use a scratch buffer for the login name.

I looked into this, and it's easy enough to change glob.c to use the 
tail of the scratch buffer that it's already using for getpwnam_r (given 
your previously-proposed patches), and this simplifies glob's 
memory-allocation code. I installed the attached patch into Gnulib to do 
that. Please take a look at it for your next go-round with glibc. Thanks.

This is mostly-theoretical stuff, of course, as this code is exercised 
only when $HOME is unset or empty.

> +	      char user_name[LOGIN_NAME_MAX];

A nit: that array needs to be one byte bigger, for the trailing NULL. 
This point is irrelevant to the attached Gnulib patch, which doesn't use 
LOGIN_NAME_MAX.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-glob-fix-bugs-with-long-login-names.patch
Type: text/x-patch
Size: 5491 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20170902/cca61803/attachment.bin>


More information about the Libc-alpha mailing list