Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

::errno

49 views
Skip to first unread message

Bonita Montero

unread,
Jun 8, 2020, 2:09:41 PM6/8/20
to
Can ayone here tell me why I can't access errno
with the ::-prefix ?

guinne...@gmail.com

unread,
Jun 8, 2020, 2:17:17 PM6/8/20
to
On Monday, 8 June 2020 19:09:41 UTC+1, Bonita Montero wrote:
> Can ayone here tell me why I can't access errno
> with the ::-prefix ?

Because errno is defined as a macro.

22.4 Error numbers [errno]
1 The contents of the header <cerrno> are the same as the POSIX header
<errno.h>, except that errno shall be defined as a macro.
[ Note: The intent is to remain in close alignment with the POSIX standard.
— end note ]
A separate errno value shall be provided for each thread.

Bonita Montero

unread,
Jun 8, 2020, 2:21:53 PM6/8/20
to
>> Can ayone here tell me why I can't access errno
>> with the ::-prefix ?

> Because errno is defined as a macro.

I "compiled" just with preprocessing-output and
errno is not substituted but stays as errno.

James Kuyper

unread,
Jun 8, 2020, 2:59:22 PM6/8/20
to
What POSIX says is:
"Any conflict between the requirements described here and the ISO C
standard is unintentional."
...
"The symbol errno shall expand to a modifiable lvalue of type int. It is
unspecified whether errno is a macro or an identifier declared with
external linkage."

Section 17.5 paragraph 2 of the C standard lists the macros #defined in
<errno.h>, and errno is on that list. It goes on to specify that "errno
... expands to a modifiable lvalue 201) that has type int and thread
local storage duration ...".

Since the C standard explicitly describes errno as a macro, having it be
an "identifier declared with external linkage" would be in conflict with
the C standard's. As all such conflicts are explicitly declared to be
unintentional, that option presumably is not actually permitted.
However, the expansion of errno is allowed to be such an identifier.

The wording actually used, however, allows other possibilities, such as

# define errno (*__errno_location ())

which is how errno is defined in /usr/include/errno.h on my system.

Paavo Helde

unread,
Jun 8, 2020, 3:08:53 PM6/8/20
to
This does not refute the C++ standard (19.4 [errno]):

"The contents of the header <cerrno> are the same as the POSIX header
<errno.h>, except that errno shall be defined as a macro."

In my quick test errno got replaced by (*__errno()).

Keith Thompson

unread,
Jun 8, 2020, 4:20:17 PM6/8/20
to
In fact the C standard has required errno to be a macro since C89/C90.
I'd say that this statement in POSIX:
It is unspecified whether errno is a macro or an identifier declared
with external linkage.
is an error (though a fairly minor one) and that sentence should be
deleted, and the preceding sentence:
The <errno.h> header shall provide a declaration or definition for
errno.
should be updated to state that <errno.h> shall provide a macro
definition for errno.

(POSIX apparently goes back to 1998. I wonder if that wording was
based on an earlier draft of ANSI C and never updated.)

--
Keith Thompson (The_Other_Keith) Keith.S.T...@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

James Kuyper

unread,
Jun 8, 2020, 4:25:48 PM6/8/20
to
The simplest and most reliable way to determine whether errno is a macro
is

#include <cerrno>
#ifdef errno

It's permissible for a macro named errno to have an expansion that is
also errno. Such an expansion would not be infinitely recursive - the
rules for macros are designed to prevent such things. However, if it
is #defined that way, then errno must also have a non-macro declaration.
In that case, if ::errno doesn't work, that implies that it's declared in
some other namespace.

I'd recommend determining the actual file that is being used (gcc's -E
option can be useful for that), and then looking in that file to see how
errno is actually #defined by your implementation.

Pavel

unread,
Jun 14, 2020, 12:25:52 AM6/14/20
to
more like 1988 if you believe to Wikipedia. I recall first learning about it
circa 1993. Back then, any reference to UNIX would elicit a quip "which UNIX?"
from one shrewd friend of mine.

-Pavel

Keith Thompson

unread,
Jun 14, 2020, 2:16:32 AM6/14/20
to
Pavel <pauldont...@removeyourself.dontspam.yahoo> writes:
> Keith Thompson wrote:
[...]
>> (POSIX apparently goes back to 1998.
> more like 1988 if you believe to Wikipedia. I recall first learning about it
> circa 1993. Back then, any reference to UNIX would elicit a quip "which UNIX?"
> from one shrewd friend of mine.

In fact Wikipedia is where I got that information. I blame the
standard that puts the '8' and '9' keys next to each other on
my keyboard. (Yes, I meant to type 1988.)

woodb...@gmail.com

unread,
Jun 14, 2020, 10:35:34 PM6/14/20
to
I ran into problems with ::FILE. Don't remember
the details now.


Brian
Ebenezer Enterprises - Enjoying programming again.
https://webEbenezer.net
0 new messages