Date: Sun, 19 May 2013 20:37:30 -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 08:21 PM, Rich Felker wrote: > On Sun, May 19, 2013 at 08:09:03PM -0400, Z. Gilboa wrote: >>> 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: > I was just looking at dynlink.c, but we could consider whether the > same issue applies in other places. I doubt the same function would be > useful in other places though since some of the logic I'd want to > factor would be dynlink-specific. Basically, I would want the function > to also encapsulate the dynlink error handling code (usually longjmp > or printing an error message). alles klar... > >> dynlink.c: all functions that call snprintf >> syslog.c: _vsyslog > Indeed there's a question of what syslog should do when the message is > too long. But unboundedly-long messages can't really be supported > anyway; the ultimate upper limit is the max unix socket datagram size. > >> getnameinfo >> inet_ntop (unsure) > Not necessary. All strings here are highly bounded in size, and in > most (all?) places they're using caller-provided buffers anyway. > >> 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) > I'm not sure what you're saying here. All of the strings here are > highly bounded in size, as you noted. There's certainly no need for > dynamic allocation of the name buffer, which would introduce an > additional failure case. My mistake. I wasn't sure why the size of _tmp_ was different, however I now see that the two sizes are independent of one another. > > 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.