Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sun, 19 May 2013 20:37:30 -0400
From: "Z. Gilboa" <>
To: <>
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
>> (, 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.