Re: patch: make the size of errbuf configurable

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

On 05/19/2013 06:09 PM, Rich Felker wrote:
> On Sun, May 19, 2013 at 05:51:05PM -0400, Z. Gilboa wrote:
>>> My preference is that either long pathnames should be truncated in a
>>> reasonable way (keep in mind that the message is *not* parsable by the
>>> caller; the only way it can be used is presenting it to the user)
>> certainly; the initial motivation was log-file processing.
>>
>>> or
>>> larger buffers should be dynamically allocated. The only reason I did
>>> not go the dynamic-allocation path to begin with was to make it so
>>> non-thread-safe usage of dlerror yields (at worst) corrupted messages
>>> rather than crashes. This can also be achieved with dynamic allocation
>>> (as long as the old too-short buffer is never freed), but it's more
>>> complex.
>> In my understanding, the current approach of having a fixed buffer
>> size is by far the superior one.
> Could you elaborate as to why? Are you concerned about memory usage?
> Code complexity? Or some other reason?
A little bit of both, with complexity being the main factor.  As far as 
I can tell (from looking at dynlink.c and otherwise), there is only one 
case (do_relocs) where both the library name and symbol name are sent to 
the buffer.  So given the case's rarity and singularity, I would not 
introduce "complex" code or memory allocation into the function.  We 
should also remember that this is not about how the error is being 
handled, only about how it is being presented, meaning that less code is 
probably better...

>
> Rich