This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: Binary compatibility loss regarding errno
- From: Kaz Kylheku <kaz at ashi dot footprints dot net>
- To: Kevin Layer <layer at franz dot com>
- Cc: libc-alpha at sources dot redhat dot com
- Date: Mon, 10 Mar 2003 14:36:22 -0800 (PST)
- Subject: Re: Binary compatibility loss regarding errno
On Mon, 10 Mar 2003, Kevin Layer wrote:
> Date: Mon, 10 Mar 2003 13:36:48 -0800
> From: Kevin Layer <layer at franz dot com>
> To: libc-alpha at sources dot redhat dot com
> Subject: [libc-alpha] Re: Binary compatibility loss regarding errno
>
> >> Consider this program:
> >>
> >> int rename (const char *, const char *);
> >> extern int errno;
> >>
> >> int main()
> >> {
> >> printf ("%d\n", errno);
> >> errno = 1;
> >> printf ("%d\n", errno);
> >> rename ("foof", "barf");
> >> printf ("%d\n", errno);
> >> return 0;
> >> }
>
> I've read all the messges in this thread in the mailing list archive
> (found via googling), and I can't quite tell if there is a conclusion
> and what that is. Will RH 8.1 (final) maintain binary compatibility
> with respect to errno?
This program is wrong.
errno is a macro defined in <errno.h>, not a symbol with external
linkage. Even ANSI C says that it is a macro. (Of course, a conforming
implementation *may* have an ``extern int errno'' and a trivial macro
that substitutes errno for errno, but such an implementation can't
support threads).
This is what it means to to preserve binary compatibility of errno:
to preserve the of the macroexpansion of the errno macro, so that
existing compiled binaries won't break.
If in one version of a library, errno expands to (*__errno_location())
then for binary compatibility, in the next version of the library,
there has to be an __errno_location() function, even if that library
has a new version of the errno macro which does something different,
like expand to (*__errno_location_2())
If RH 8.1 somehow breaks binary compatibility for errno, it will not be
a useable release; I would call that a showstopper bug. So in other
words, I would not worry about this.