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 */

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".

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 file’s
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 */