From Newsgroup: comp.std.c

A footnote in the section describing <errno.h> says:

The macro errno need not be the identifier of an object. It might
expand to a modifiable lvalue resulting from a function call (for
example, *errno()).

Footnotes are non-normative, and this one is presumably intended to be informal, but that's not a valid macro definition for errno, both
because it's not fully protected by parentheses and because the function
can't be named "errno".

A valid definition (and the one used by glibc) is:

# define errno (*__errno_location ())

I suggest the footnote should be updated to use something like that
(though it needn't show the entire #define directive).

The same wording appears starting in C90 and up to and including the
latest C23 draft.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.std.c

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

A footnote in the section describing <errno.h> says:

The macro errno need not be the identifier of an object. It might
expand to a modifiable lvalue resulting from a function call (for
example, *errno()).

Footnotes are non-normative, and this one is presumably intended to be informal, but that's not a valid macro definition for errno, both
because it's not fully protected by parentheses and because the function can't be named "errno".

I see no reason the function couldn't be named "errno".
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.std.c

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

A footnote in the section describing <errno.h> says:

The macro errno need not be the identifier of an object. It might
expand to a modifiable lvalue resulting from a function call (for
example, *errno()).

Footnotes are non-normative, and this one is presumably intended to be
informal, but that's not a valid macro definition for errno, both
because it's not fully protected by parentheses and because the function
can't be named "errno".

I see no reason the function couldn't be named "errno".

My thought was that giving the function and the macro the same name
would cause a conflict, and I thought I had an example that demonstrated
it. Looking again, I was mistaken:

If the name of the macro being replaced is found during this scan of
the replacement list (not including the rest of the source filerCOs
preprocessing tokens), it is not replaced.

I still suggest that using the same name for both is needlessly
confusing.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.21d-Linux NewsLink 1.2