[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130519214800.GH20323@brightrain.aerifal.cx>
Date: Sun, 19 May 2013 17:48:00 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: patch: make the size of errbuf configurable
On Sun, May 19, 2013 at 11:36:05PM +0200, Luca Barbato wrote:
> On 05/19/2013 11:05 PM, Szabolcs Nagy wrote:
> > * Z. Gilboa <zg7s@...rvices.virginia.edu> [2013-05-19 16:12:58 -0400]:
> >> When a shared library that resides in a deeply nested folder
> >> contains unresolved (long-named, mangled) symbols, the displayed
> >> name of the library and/or symbol might get truncated. The attached
> >> patch makes the size of errbuf (ldso/dynlink.c) configurable
> >> (--with-ld-errbuf-size), while yet leaving the default size of 128
> >> unaffected.
> >
> > i dont think this is the best place to start adding configurations
> >
> > i'd prefer simply increasing the buffer if this is an issue
> >
> > c++ mangled names can get pretty insane, i just checked my system
>
> check boost-spirit for the most amazing results (we are talking
> kilobytes for a single symbol)
In this case, I tend to think the current limit is just a bug. It
should suffice to just keep track of the current buffer size and
malloc a new buffer when a larger message is needed, leaving the old
message forever in the previous buffer. To avoid too many such
allocations, size can be doubled each time it's insufficient. If
allocation fails, the error message can be replaced with "internal
dynamic linker allocation failure" which will always fit in the old
buffer.
Note that in a correct program, the buffer should never be used
anyway, so it shouldn't lead to bloat.
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.
