This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Bumping _SC_GET*_R_SIZE_MAX to 4096?
- From: Rich Felker <dalias at aerifal dot cx>
- To: Carlos O'Donell <carlos at redhat dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Fri, 10 Jul 2015 21:26:23 -0400
- Subject: Re: Bumping _SC_GET*_R_SIZE_MAX to 4096?
- Authentication-results: sourceware.org; auth=none
- References: <559FC12E dot 2030904 at redhat dot com>
On Fri, Jul 10, 2015 at 08:57:18AM -0400, Carlos O'Donell wrote:
> Over the years I've seen requests to bump
> the _SC_GET*_R_SIZE_MAX constant from 1024
> to 4096. Apparently there are systems where
> the smaller buffer always forces a reallocation
> and I'm told that Mac OSX already uses 4096
> for these constants.
When you say "systems", what exactly do you mean? Are there whole
classes of glibc deployments that need a larger buffer size for some
reason? Or is it just an issue for sites with huge gecos fields or
something?
Given how expensive these lookup operations themselves are, I think
the reallocation itself is negligible. However, if the whole operation
has to be repeated because of unsufficient output buffer space, that's
unfortunate and effectively doubles the lookup time. (Whether this is
the case probably depends on whether nscd is in use...?)
> Are there any implications, other than increased
> application memory usage?
I don't think so, but the proposed increase in memory usage is
somewhat substantial, especially for small systems. Maybe this doesn't
matter in environments where glibc is used/useful, though.
Rich