bug-groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Current CVS: incorrect re-decrlaration of errno


From: Ted Harding
Subject: Re: Current CVS: incorrect re-decrlaration of errno
Date: Sat, 23 Sep 2000 12:01:29 +0100 (BST)

On 22-Sep-00 Werner LEMBERG wrote:
>> #include <errno.h>
>> ...
>> #ifndef errno
>> extern int errno;
>> #endif
>> 
>> This is plain wrong; you cannot assume that errno is #define'd. It
>> is *declared* in <errno.h> and the second redeclaration fails for
>> C++ (well, it may be subtle namespace problem - our compiler does
>> some tricks with namespaces in standard includes).
> 
> At least for C you are wrong.  According to the ISO C standard, errno
> may be a macro (and glibc indeed uses a macro).  I'll have a look into
> the C++ standard, but I doubt this has changed since it would break
> backwards compatibility.

This may not be straightforward. In my Linux gcc, the result of
#include <errno.h> is that, somewhere along the chain, the following
happens (/usr/include/errno.h  ANSI Standard: 4.1.3 Errors <errno.h>):

  #if defined(_POSIX_THREAD_SAFE_FUNCTIONS) || defined(_REENTRANT)
  extern int*     __errno_location  __P((void));
  #define errno   (*__errno_location ())
  #else
  extern int errno;
  #endif

so that, for the same "#include <errno.h>", you could get errno
either defined as a macro or declared as extern int; but in either
case this occurs when <errno.h> is first read.

Since #ifdef returns true only for macro definitions, when <errno.h>
has already been included there is the possibility that errno has
already been declared as extern int in which case the second declaration
as above will clash with the first.

Without having looked into the code which gave rise to the question,
my immediate view would be that the lines

>> #ifndef errno
>> extern int errno;
>> #endif

above are superfluous, since the issue has already been sorted out
within <errno.h>. However, this may be wrong depending on the code in
question, and in any case different C/C++ compilers may approach
the matter differently.

Hope this helps!
Ted.

--------------------------------------------------------------------
E-Mail: (Ted Harding) <address@hidden>
Fax-to-email: +44 (0)870 284 7749
Date: 23-Sep-00                                       Time: 12:01:29
------------------------------ XFMail ------------------------------


reply via email to

[Prev in Thread] Current Thread [Next in Thread]