Date: Sun, 19 May 2013 20:09:03 -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 07:22 PM, Rich Felker wrote: > 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 When moving beyond dynlink.c then yes, I believe, that should be beneficial. I just had a quick look at the places where snprintf is used, and found that the following functions might benefit from the above wrapper: dynlink.c: all functions that call snprintf syslog.c: _vsyslog getnameinfo inet_ntop (unsure) sem_open (unsure: _name_ can be up to 251 characters long (http://man7.org/linux/man-pages/man7/sem_overview.7.html), but is link to _tmp_ which is only up to 64 characters long) Zvi
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.