Date: Sun, 19 May 2013 17:51:05 -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 05:03 PM, Rich Felker wrote: > On Sun, May 19, 2013 at 04:12:58PM -0400, Z. Gilboa wrote: >> Greetings, >> >> 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. > If at some point we do have build configurations, I'd want it to be > more structured, and for the user-visible names not to reflect > internal variable names, but something more meaningful to users. > > With that said, in this case I think a different solution is called > for, mainly because having configurability for such small details is > setting a precedent that, if followed, could lead to hundreds of > trivial configurable knobs and the same testability nightmare that > plagues uClibc. > > 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. And I also see your point about keeping the number of configurable options to a minimum. With this in mind, here are some alternatives: 1) remove the change from _configure_, but keep the change in _dynlink.c_ intact, which would allow developers to control the buffer size via CFLAGS. Add a note to the documentation (and configure's --help) about the option to do so. 2) discard the patch altogether, but add a list of "strategic code locations" to the documentation... Any thoughts? > > I'd welcome input on which approach users would prefer. > > 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.