[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 13 Jun 2011 00:54:18 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: Weekly reports - B
On Mon, Jun 13, 2011 at 06:56:55AM +0400, Solar Designer wrote:
> > but another way to achieve the same thing would be to install
> > the signal handler with SA_NOMASK so the SIGSEGV never gets masked to
> > [...]
>
> Thank you for mentioning these.
>
> For cluts, I think it'd be best not to go for them, though - they might
> make cluts unnecessarily less portable.
That's a good point. I seem to recall some systems (including older
Linux) having broken SA_NOMASK.
> > > Please avoid assignments to errno. Use your own variable instead.
> >
> > Is this just a stylistic preference, or do you have a reason it could
> > be problematic?
>
> Mostly a stylistic preference. errno is defined to have a specific kind
> of values assigned to it, by libc. Reusing a variable for something
> different than its original purpose makes the source code more difficult
> to understand (even if very slightly).
>
> As to actual potential issues:
>
> IIRC, some ancient versions of glibc didn't allow programs to assign to
> errno at all, because it was declared as a macro (not a variable). That
This sounds like an urban legend. errno is a macro and has been for a
long time (ever since threads) on most systems. It's required by the
standard to be an lvalue macro.
> Is it guaranteed that errno is preserved across libc calls that complete
> without error? Maybe not. I don't really know, and I'd prefer not to
> depend on that.
Unless it's documented that a particular function can't, libc
functions can clobber errno all they like, whether or not they return
failure. The only thing they can't do is set it to 0, unless they put
some other nonzero (hopefully meaningful) value in it before
returning. Note that even strerror and perror can clobber errno if
they encounter an internal error, so if you want to portably print an
error message before acting on the error, you really need to save the
value of errno right away.
This all makes using errno a little bit messy, but if libc functions
were required not to change errno except when reporting an error,
pretty much every libc function that uses other libc functions would
be full of useless bloat and slowdowns saving and restoring errno
values...
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.
