Re: patch: make the size of errbuf configurable

[Rich Felker <dalias@aerifal.cx>]

On Sun, May 19, 2013 at 06:26:04PM -0400, Z. Gilboa wrote:
> >>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...

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