From: Solar Designer <solar@openwall.com>
To: musl@lists.openwall.com
Subject: Re: Weekly reports - B
Date: Mon, 13 Jun 2011 10:48:45 +0400 [thread overview]
Message-ID: <20110613064845.GA22390@openwall.com> (raw)
In-Reply-To: <20110613045418.GQ191@brightrain.aerifal.cx>
On Mon, Jun 13, 2011 at 12:54:18AM -0400, Rich Felker wrote:
> On Mon, Jun 13, 2011 at 06:56:55AM +0400, Solar Designer wrote:
> > 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.
Oh, of course I did not recall correctly. Here's what I think this was
about: old programs such as qmail (not maintained upstream since 1998)
used "extern int errno;" instead of including errno.h, and indeed this
failed when errno became a macro (for threads, as you correctly remind
me). So this was an entirely different issue.
> > 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.
I went to:
http://pubs.opengroup.org/onlinepubs/009695399/functions/errno.html
and it does say "No function in this volume of IEEE Std 1003.1-2001
shall set errno to 0. The setting of errno after a successful call to a
function is unspecified unless the description of that function
specifies that errno shall not be modified." Which not surprisingly
matches what you wrote above.
I was a bit puzzled why they decided to outlaw setting of errno to 0 by
library functions, although this does make some sense to me (easy to
achieve and preserves at least some recent error code for poorly written
old programs).
> 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...
Good point. I guess they'd resort to calling other than exported
versions of the functions, though. But this could mean extra function
call overhead for the exported versions...
Alexander
next prev parent reply other threads:[~2011-06-13 6:48 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
2011-06-13 6:48 ` Solar Designer [this message]
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=20110613064845.GA22390@openwall.com \
--to=solar@openwall.com \
--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).