Bumping _SC_GET*_R_SIZE_MAX to 4096?

Bumping _SC_GET*_R_SIZE_MAX to 4096?

[Carlos O'Donell]

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.

Are there any implications, other than increased
application memory usage?

Cheers,
Carlos.

Re: Bumping _SC_GET*_R_SIZE_MAX to 4096?

[Rich Felker]

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