[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <5199704A.5040704@eservices.virginia.edu>
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.
