Re: Binary compatibility loss regarding errno

[Kaz Kylheku <kaz at ashi dot footprints dot net>]

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.