[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