[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5199517C.8040403@eservices.virginia.edu>
Date: Sun, 19 May 2013 18:26:04 -0400
From: "Z. Gilboa" <zg7s@...rvices.virginia.edu>
To: <musl@...ts.openwall.com>
Subject: Re: patch: make the size of errbuf configurable
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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
