mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@aerifal.cx>
To: musl@lists.openwall.com
Subject: Re: Weekly reports - B
Date: Mon, 13 Jun 2011 00:54:18 -0400	[thread overview]
Message-ID: <20110613045418.GQ191@brightrain.aerifal.cx> (raw)
In-Reply-To: <20110613025655.GA21653@openwall.com>

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


  reply	other threads:[~2011-06-13  4:54 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-09 20:20 Luka Marčetić
2011-06-12 23:13 ` Rich Felker
2011-06-13  2:11 ` Solar Designer
2011-06-13  2:22   ` Rich Felker
2011-06-13  2:56     ` Solar Designer
2011-06-13  4:54       ` Rich Felker [this message]
2011-06-13  6:48         ` Solar Designer
2011-07-06 11:35         ` errno (was: Weekly reports - B) Solar Designer
2011-07-06 12:57           ` Szabolcs Nagy
2011-07-06 13:14             ` errno Solar Designer
2011-07-07  2:56           ` errno (was: Weekly reports - B) Rich Felker
2011-06-26 21:05     ` Weekly reports - X Luka Marčetić
2011-06-26 21:13       ` rich felker
2011-06-27 22:18         ` Solar Designer
2011-07-04 19:30           ` Luka Marčetić
2011-07-04 19:39             ` Rich Felker
2011-06-13  2:22   ` specification of cluts tests - code or/and data? (was: Weekly reports - B) Solar Designer
2011-06-13  9:19     ` specification of cluts tests - code or/and data? Solar Designer
2011-07-09  6:41 ` cluts repository (was: Weekly reports - B) Solar Designer
2011-07-09 11:31   ` cluts repository Solar Designer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110613045418.GQ191@brightrain.aerifal.cx \
    --to=dalias@aerifal.cx \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).