From Newsgroup: comp.lang.c

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

Michael S <already5chosen@yahoo.com> writes:

On Mon, 04 Aug 2025 12:09:32 GMT
anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:

[...]

typedef ump unsigned _BitInt(65535);

The correct syntax is :

typedef unsigned _BitInt(65535) ump;

ump sum3(ump a, ump b, ump c)
{
return a+b+c;
}

[...]

1. Both gcc and clang happily* accept _BitInt() syntax even when
-std=c17 or lower. Is not here a potential name clash for existing
sources that use _BitInt() as a name of the function? I should think
more about it.

In C17 and earlier, _BitInt is a reserved identifier. Any attempt to
use it has undefined behavior. [...]

Not so. The C standard says if a program declares or defines a
reserved identifier (in a context where it is reserved) then the
behavior is undefined. The C standard does /not/ say that simply
using (as opposed to declaring or defining) a reserved identifier
has undefined behavior (in any context).

The C23 standard is different, but I believe what it says is
consistent with the previous paragraph.

Furthermore it is always possible to use any reserved identifier
in a way that has defined behavior, as for example:

#include <stdio.h>

#define XX(a) X(a)
#define X(a) #a

#define show(a) printf( "The id %s expands to %s\n", X(a), XX(a) )

int
main( int argc, char *argv[] ){
show( _BitInt );
return 0;
}

This program works without complaint under all of C90, C99, C11, and
C17.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

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

James Kuyper <jameskuyper@alumni.caltech.edu> writes:

On 2025-08-05 17:13, Kaz Kylheku wrote:

On 2025-08-04, Michael S <already5chosen@yahoo.com> wrote:

On Mon, 4 Aug 2025 15:25:54 -0400
James Kuyper <jameskuyper@alumni.caltech.edu> wrote:

...

If _BitInt is accepted by older versions of gcc, that means it
was supported as a fully-conforming extension to C. Allowing
implementations to support extensions in a fully-conforming
manner is one of the main purposes for which the standard
reserves identifiers. If you thought that gcc was too
conservative to support extensions, you must be thinking of the
wrong organization.

I know that gcc supports extensions.
I also know that gcc didn't support *this particular extension*
up until quite recently.

I think what James means is that GCC supports, as an extension,
the use of any _[A-Z].* identifier whatsoever that it has not
claimed for its purposes.

No, I meant very specifically that if, as reported, _BitInt was
supported even in earlier versions, then it was supported as an
extension.

gcc 13.4.0 does not recognize _BitInt at all.

gcc 14.2.0 handles _BitInt as a language feature in C23 mode,
and as an "extension" in pre-C23 modes.

It warns about _BitInt with "-std=c17 -pedantic", but not with
just "-std=c17". I think I would have preferred a warning with
"-std=c17", but it doesn't bother me. There's no mention of _BitInt
as an extension or feature in the documentation. An implementation
is required to document the implementation-defined value of
BITINT_MAXWIDTH, so that's a conformance issue. In pre-C23 mode,
since it's not documented, support for _BitInt is not formally an "extension"; it's an allowed behavior in the presence of code that
has undefined behavior due to its use of a reserved identifier.
(This is a picky language-lawyerly interpretation.)

To clarify the last part, undefined behavior is allowed only
because a diagnostic was generated. If there were no diagnostic
then it would have to be documented as an extension, otherwise
the implementation would not be conforming.
--- Synchronet 3.21a-Linux NewsLink 1.2