[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110722133021.GF132@brightrain.aerifal.cx>
Date: Fri, 22 Jul 2011 09:30:21 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: some fixes to musl
On Fri, Jul 22, 2011 at 12:19:10PM +0400, Vasiliy Kulikov wrote:
> On Thu, Jul 21, 2011 at 23:00 +0400, Solar Designer wrote:
> > Personally, I've been using different approaches to this in different
> > ones of my programs. For musl, I think the "always check" approach may
> > be the better one. Yes, the code size increase from those error
> > handling paths is unfortunate... Some use of goto can make them smaller
> > and keep them out of the same cache lines with actually running code.
>
> The problem here is that there might be no good way to handle errors
> of error handling code. If we allocate resource A, then B, and B
> allocation fails, we should release A and return error code. What to do
> if releasing A fails? Return error code and leave A allocated
> (==leaked)? Try to release it in a cycle (potential infinite loop)?
> Terminate the process (not expected by the caller)?
>
> I don't have a good solution...
The good solution is to demand that kernel developers not create such
bugs and calling them out on it when they do...
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.
