Re: patch: make the size of errbuf configurable

[Rich Felker <dalias@aerifal.cx>]

On Sun, May 19, 2013 at 08:09:03PM -0400, Z. Gilboa wrote:
> > From what I can see, complexity can be avoided and maybe even reduced
> >by refactoring the code so that all the places that set an error
> >message call a short simple function that wraps snprintf and allocates
> >a new buffer if needed. The complexity reduction would be if we can
> >eliminate duplicate logic at each call point, which I haven't checked
> >yet.
> >
> >Rich
> 
> When moving beyond dynlink.c then yes, I believe, that should be
> beneficial.  I just had a quick look at the places where snprintf is
> used, and found that the following functions might benefit from the
> above wrapper:

I was just looking at dynlink.c, but we could consider whether the
same issue applies in other places. I doubt the same function would be
useful in other places though since some of the logic I'd want to
factor would be dynlink-specific. Basically, I would want the function
to also encapsulate the dynlink error handling code (usually longjmp
or printing an error message).

> dynlink.c:    all functions that call snprintf
> syslog.c:    _vsyslog

Indeed there's a question of what syslog should do when the message is
too long. But unboundedly-long messages can't really be supported
anyway; the ultimate upper limit is the max unix socket datagram size.

> getnameinfo
> inet_ntop (unsure)

Not necessary. All strings here are highly bounded in size, and in
most (all?) places they're using caller-provided buffers anyway.

> sem_open (unsure: _name_ can be up to 251 characters long
> (http://man7.org/linux/man-pages/man7/sem_overview.7.html), but is
> link to _tmp_ which is only up to 64 characters long)

I'm not sure what you're saying here. All of the strings here are
highly bounded in size, as you noted. There's certainly no need for
dynamic allocation of the name buffer, which would introduce an
additional failure case.

Rich