Date: Sun, 19 May 2013 20:21:19 -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 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). > 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. 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.