Re: patch: make the size of errbuf configurable

["Z. Gilboa" <zg7s@eservices.virginia.edu>]

On 05/19/2013 08:21 PM, Rich Felker wrote:
> 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).
alles klar...
>
>> 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.
My mistake.  I wasn't sure why the size of _tmp_ was different, however 
I now see that the two sizes are independent of one another.

>
> Rich