From Newsgroup: comp.lang.c

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

Michael S <already5chosen@yahoo.com> writes:

Actually, in our world the latest C standard (C23) has them, but the >spelling is different: _BitInt(32) and unsigned _BitInt(32).
I'm not sure if any major compiler already has them implemented. Bing >copilot says that clang does, but I don't tend to believe eveything
Bing copilot says.

I asked godbolt, and tried the following program:

It turned out that I didn't need even goldbolt.
I already had sufficiently advanced gcc and clang installed on my new
Windows PC at work. I probably have them installed on very old home PC
as well, but now I am at work. Playing with compilers instead of
working.

typedef ump unsigned _BitInt(65535);

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

and for the C setting gcc-15.1 AMD64 produces 129 lines of assembly
language code; for C++ it complains about the syntax. For 65536 bits,
it complains about being beyond the maximum number of 65535 bits.

For the same program with the C setting clang-20.1 produces 29547
lines of assembly language code; that's more than 28 instructions for
every 64-bit word of output, which seems excessive to me, even if you
don't use ADX instructions (which clang apparently does not); I expect
that clang will produce better code at some point in the future.
Compiling this function also takes noticable time, and when I ask for
1000000 bits, clang still does complain about too many bits, but
godbolt's timeout strikes; I finally found out clang's limit: 8388608
bits. On clang-20.1 the C++ setting also accepts this kind of input.

Followups set to comp.arch.

- anton

I didn't pay much attention to code size yet. Had seen two other
worrying things.

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.

2. Windows-specific.
gcc and clang appear to have different ABIs for return value of type _BitInt(128).


* - the only sign of less than perfect happiness is a warning produced
with -pedantic flag.


Cross-posted to c.lang.c


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

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. That's exactly why new keywords are
often defined with that ugly syntax.

Both gcc and clang warn about _BitInt with invoked with "-std=c17 -pedantic".

[...]

* - the only sign of less than perfect happiness is a warning produced
with -pedantic flag.

Yes, both are behaving reasonably. If you don't use "-pedantic",
you're telling the compiler you don't want standard conformance.
(I'd be happier if conformance were the default, but we're stuck
with it.) But accepting _BitInt in pre-C23 mode is conforming.

Cross-posted to c.lang.c

I've kept the cross-post to comp.lang.c and comp.arch.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On Mon, 04 Aug 2025 09:53:51 -0700
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

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. That's exactly why new keywords are
often defined with that ugly syntax.

That is language lawyer's type of reasoning. Normally gcc maintainers
are wiser than that because, well, by chance gcc happens to be widely
used production compiler. I don't know why this time they had chosen
less conservative road.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 2025-08-04 15:03, Michael S wrote:

On Mon, 04 Aug 2025 09:53:51 -0700
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

...

In C17 and earlier, _BitInt is a reserved identifier. Any attempt to
use it has undefined behavior. That's exactly why new keywords are
often defined with that ugly syntax.

That is language lawyer's type of reasoning. Normally gcc maintainers
are wiser than that because, well, by chance gcc happens to be widely
used production compiler. I don't know why this time they had chosen
less conservative road.

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.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

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

On 2025-08-04 15:03, Michael S wrote:

On Mon, 04 Aug 2025 09:53:51 -0700
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

...

In C17 and earlier, _BitInt is a reserved identifier. Any attempt
to use it has undefined behavior. That's exactly why new keywords
are often defined with that ugly syntax.

That is language lawyer's type of reasoning. Normally gcc
maintainers are wiser than that because, well, by chance gcc
happens to be widely used production compiler. I don't know why
this time they had chosen less conservative road.

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 would guess, up until this calendar year.
Introducing new extension without way to disable it is different from supporting gradually introduced extensions, typically with names that
start by double underscore and often starting with __builtin.

BTW, I still didn't think deeply about it and still hope that outside
of C23 mode gcc somehow cared to make name clash unlikely.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 8/4/2025 12:40 PM, Michael S wrote:

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

On 2025-08-04 15:03, Michael S wrote:

On Mon, 04 Aug 2025 09:53:51 -0700
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

...

In C17 and earlier, _BitInt is a reserved identifier. Any attempt
to use it has undefined behavior. That's exactly why new keywords
are often defined with that ugly syntax.

That is language lawyer's type of reasoning. Normally gcc
maintainers are wiser than that because, well, by chance gcc
happens to be widely used production compiler. I don't know why
this time they had chosen less conservative road.

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 would guess, up until this calendar year.
Introducing new extension without way to disable it is different from supporting gradually introduced extensions, typically with names that
start by double underscore and often starting with __builtin.

Well, if there is an "new exotic" extension in a C compiler that does
_not_ have the ability to be turned on or off, would be "bad"... Well,
it can be a way to sort of try to "lock" one into a compiler?

BTW, I still didn't think deeply about it and still hope that outside
of C23 mode gcc somehow cared to make name clash unlikely.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

Michael S <already5chosen@yahoo.com> writes:

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

On 2025-08-04 15:03, Michael S wrote:

On Mon, 04 Aug 2025 09:53:51 -0700
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

...

In C17 and earlier, _BitInt is a reserved identifier. Any attempt
to use it has undefined behavior. That's exactly why new keywords
are often defined with that ugly syntax.

That is language lawyer's type of reasoning. Normally gcc
maintainers are wiser than that because, well, by chance gcc
happens to be widely used production compiler. I don't know why
this time they had chosen less conservative road.

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 would guess, up until this calendar year.
Introducing new extension without way to disable it is different from supporting gradually introduced extensions, typically with names that
start by double underscore and often starting with __builtin.

BTW, I still didn't think deeply about it and still hope that outside
of C23 mode gcc somehow cared to make name clash unlikely.

Using the keyword _BitInt makes name clashes nearly impossible.

In C23, it's a new keyword. In pre-C23, it's an
implementation-defined keyword that will not clash with any
identifier that any portable code will use, or that any non-portable
code is at all likely to use for anything other than its new
standard meaning.

Breaking existing code that uses "_BitInt" as an identifier is
a non-issue. There very probably is no such code.

The feature can be disabled by not using "_BitInt" in your code,
or by using the "-pedantic-errors" option with a standard earlier
than C23.

I'm not sure how much more conservative gcc could have been.
(Likewise for clang.)
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

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

On Mon, 04 Aug 2025 09:53:51 -0700
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

In C17 and earlier, _BitInt is a reserved identifier. Any attempt to
use it has undefined behavior. That's exactly why new keywords are
often defined with that ugly syntax.

That is language lawyer's type of reasoning. Normally gcc maintainers
are wiser than that because, well, by chance gcc happens to be widely
used production compiler. I don't know why this time they had chosen
less conservative road.

They invented an identifer which lands in the _[A-Z].* namespace
designated as reserved by the standard.

What would be an exmaple of a more conservative way to name the
identifier?
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

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:

On 2025-08-04 15:03, Michael S wrote:

On Mon, 04 Aug 2025 09:53:51 -0700
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

...

In C17 and earlier, _BitInt is a reserved identifier. Any attempt
to use it has undefined behavior. That's exactly why new keywords
are often defined with that ugly syntax.

That is language lawyer's type of reasoning. Normally gcc
maintainers are wiser than that because, well, by chance gcc
happens to be widely used production compiler. I don't know why
this time they had chosen less conservative road.

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.

(I don't know that to be true; an extension has to be documented other
than by omission. But anyway, if the GCC documentation says somewhere
something like, "no other identifier is reserved in this version of
GCC", then it means that the remaining portions of the reserved
namespaces are available to the program. Since it is undefined behavior
to use those identifiers (or in certain ways in certain circumstances,
as the case may be), being able to use them with the documentation's
blessing constitutes use of a documented extension.)

I would guess, up until this calendar year.
Introducing new extension without way to disable it is different from supporting gradually introduced extensions, typically with names that
start by double underscore and often starting with __builtin.

__builtin also in a standard-defined reserved namespace; the double
underscore namespace. It is no more or less conservative to name
something __bitInt as _BitInt.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 2025-08-05, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

Breaking existing code that uses "_BitInt" as an identifier is
a non-issue. There very probably is no such code.

However, that doesn't mean GCC can carelessly introduce identifiers
in this namespace.

GCC does not define a complete C implementation; it doesn't provide a
library. Libraries are provided by other projects: Glibc, Musl,
ucLibc, ...

Those libraries are C implementors also, and get to name things
in the reserved namespace.

It would be unthinkable for GCC to introduce, say, an extension
using the identifier __libc_malloc.

In addition to libraries, if some other important project that serves as
a base package in many distributions happens to claim identifiers in
those spaces, it wouldn't be wise for GCC (or the C libraries) to start
taking them away.

You can't just rename the identifier out of the way in the offending
package, because that only fixes the issue going forward. Older versions
of the package can't be compiled with the new compiler without a patch. Compiling older things with newer GCC happens.

There are always the questions:

1. Is there an issue? Is anything broken?

2. If so, is what is broken important such that it becomes a showstopper
if the compiler change is rolled out (major distros are on fire?)
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

Kaz Kylheku <643-408-1753@kylheku.com> writes:

On 2025-08-05, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

Breaking existing code that uses "_BitInt" as an identifier is
a non-issue. There very probably is no such code.

However, that doesn't mean GCC can carelessly introduce identifiers
in this namespace.

Agreed -- and in gcc did not do that in this case. I was referring to
_BitInt, not to other identifiers in the reserved namespace.

Do you have any reason to believe that gcc's use of _BitInt will break
any existing code? My best guess is that there is no such code, that
the only real world uses of the name _BitInt are deliberate uses of the
new C23 feature, and that gcc's support of _BitInt in non-C23 mode
will not break anything.

It is of course possible that I'm wrong.

If the name _BitInt did break (non-portable) existing C code, then the
fault would lie with the C committee, not with the gcc maintainers.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 2025-08-06, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

Kaz Kylheku <643-408-1753@kylheku.com> writes:

On 2025-08-05, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

Breaking existing code that uses "_BitInt" as an identifier is
a non-issue. There very probably is no such code.

However, that doesn't mean GCC can carelessly introduce identifiers
in this namespace.

Agreed -- and in gcc did not do that in this case. I was referring to _BitInt, not to other identifiers in the reserved namespace.

Do you have any reason to believe that gcc's use of _BitInt will break
any existing code?

It has landed, and we don't hear reports that the sky is falling.

If it does break someone's obscure project with few users, unless that
person makes a lot of noise in some forums I read, I will never know.

My position has always been to think about the threat of real,
or at least probable clashes.

I can turn it around: I have not heard of any compiler or library using _CreamPuff as an identifier, or of a compiler which misbehaves when a
program uses it, on grounds of it being undefined behavior. Someone
using _CreamPuff in their code is taking a risk that is vanishingly
small, the same way that introducing _BigInt is a risk that is
vanishingly small.

In fact, in some sense the risk is smaller because the audience of
programs facing an implementation (or language) that has introduced some identifier is vastly larger than the audience of implementations that a
given program will face that has introduced some funny identifier.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On Wed, 6 Aug 2025 04:31:59 -0000 (UTC)
Kaz Kylheku <643-408-1753@kylheku.com> wrote:

On 2025-08-06, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

Kaz Kylheku <643-408-1753@kylheku.com> writes:

On 2025-08-05, Keith Thompson <Keith.S.Thompson+u@gmail.com>
wrote:

Breaking existing code that uses "_BitInt" as an identifier is
a non-issue. There very probably is no such code.

However, that doesn't mean GCC can carelessly introduce identifiers
in this namespace.

Agreed -- and in gcc did not do that in this case. I was referring
to _BitInt, not to other identifiers in the reserved namespace.

Do you have any reason to believe that gcc's use of _BitInt will
break any existing code?

It has landed, and we don't hear reports that the sky is falling.

If it does break someone's obscure project with few users, unless that
person makes a lot of noise in some forums I read, I will never know.

Exactly.
The World is a very big place. Even nowadays it is not completely
transparent. Even those parts that are publicly visible in theory not necessarily had been had been observed recently by a single person even
if the person in question is Keith.
Besides, according to my understanding majority of gcc users didn't yet
migrate to gcc14 or 15.

My position has always been to think about the threat of real,
or at least probable clashes.

I can turn it around: I have not heard of any compiler or library
using _CreamPuff as an identifier, or of a compiler which misbehaves
when a program uses it, on grounds of it being undefined behavior.
Someone using _CreamPuff in their code is taking a risk that is
vanishingly small, the same way that introducing _BigInt is a risk
that is vanishingly small.

In fact, in some sense the risk is smaller because the audience of
programs facing an implementation (or language) that has introduced
some identifier is vastly larger than the audience of implementations
that a given program will face that has introduced some funny
identifier.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

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.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

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

On 2025-08-05, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

Breaking existing code that uses "_BitInt" as an identifier is
a non-issue. There very probably is no such code.

However, that doesn't mean GCC can carelessly introduce identifiers
in this namespace.

GCC does not define a complete C implementation; it doesn't provide a library. Libraries are provided by other projects: Glibc, Musl,
ucLibc, ...

Those libraries are C implementors also, and get to name things
in the reserved namespace.

GCC cannot be implemented in such a way as to create a fully conforming implementation of C when used in connection with an arbitrary
implementation of the C standard library. This is just one example of a
more general potential problem: Both gcc and the library must use some
reserved identifiers, and they might have made conflicting choices.
That's just one example of the many things that might prevent them from
being combined to form a conforming implementation of C. It doesn't mean
that either one is defective. It does mean that the two groups of
implementors should consider working together to resolve the conflicts.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

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.)
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 2025-08-05 23:08, Kaz Kylheku wrote:

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

On Mon, 04 Aug 2025 09:53:51 -0700
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

In C17 and earlier, _BitInt is a reserved identifier. Any attempt to
use it has undefined behavior. That's exactly why new keywords are
often defined with that ugly syntax.

That is language lawyer's type of reasoning. Normally gcc maintainers
are wiser than that because, well, by chance gcc happens to be widely
used production compiler. I don't know why this time they had chosen
less conservative road.

They invented an identifer which lands in the _[A-Z].* namespace
designated as reserved by the standard.

What would be an exmaple of a more conservative way to name the
identifier?

What is actually going on is GCC offering its users a gradual way to transition from C17 to C23, by applying the C23 meaning of any C23
construct that has no conflicting meaning in C17 . In particular, this
allows installed library headers to use the new types as part of
logically opaque (but compiler visible) implementation details, even
when those libraries are used by pure C17 programs. For example, the
ISO POSIX datatype struct stat could contain a _BitInt(128) type for
st_dev or st_ino if the kernel needs that, as was the case with the 1996
NT kernel . Or a _BitInt(512) for st_uid as used by that same kernel .

GCC --pedantic is an option to check if a program is a fully conforming portable C program, with the obvious exception of the contents of any
used "system" headers (including installed libc headers), as those are
allowed to implement standard or non-standard features in implementation specific ways, and might even include implementation specific logic to
report the use of non-standard extensions to the library standards when
the compiler is invoked with --pedantic and no contrary options .

I am unsure how GCC --pedantic deals with the standards-contrary
features in the GNUC89 language, such as the different type of (foo,
'C') (GNUC says char, C89 says int), maybe specifying standard C instead
of GNUC reverts those to the standard definition .

Enjoy

Jakob
--
Jakob Bohm, MSc.Eng., I speak only for myself, not my company
This public discussion message is non-binding and may contain errors
All trademarks and other things belong to their owners, if any.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

Jakob Bohm <egenagwemdimtapsar@jbohm.dk> writes:
[...]

I am unsure how GCC --pedantic deals with the standards-contrary
features in the GNUC89 language, such as the different type of (foo,
'C') (GNUC says char, C89 says int), maybe specifying standard C
instead of GNUC reverts those to the standard definition .

I'm not sure what you're referring to. You didn't say what foo is.

I believe that in all versions of C, the result of a comma operator has
the type and value of its right operand, and the type of an unprefixed character constant is int.

Can you show a complete example where `sizeof (foo, 'C')` yields
sizeof (int) in any version of GNUC?
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 18/08/2025 06:18, Keith Thompson wrote:

Jakob Bohm <egenagwemdimtapsar@jbohm.dk> writes:
[...]

I am unsure how GCC --pedantic deals with the standards-contrary
features in the GNUC89 language, such as the different type of (foo,
'C') (GNUC says char, C89 says int), maybe specifying standard C
instead of GNUC reverts those to the standard definition .

I'm not sure what you're referring to. You didn't say what foo is.

I believe that in all versions of C, the result of a comma operator has
the type and value of its right operand, and the type of an unprefixed character constant is int.

Can you show a complete example where `sizeof (foo, 'C')` yields
sizeof (int) in any version of GNUC?

$ cat so.c
#include <stdio.h>

int main(void)
{
int foo = 42;
size_t soa = sizeof (foo, 'C');
size_t sob = sizeof foo;
printf("%s.\n", (soa == sob) ? "Yes" : "No");
return 0;
}
$ gcc -o so so.c
$ ./so
Yes.
$ gcc --version
gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 18.08.2025 07:18, Keith Thompson wrote:

Jakob Bohm <egenagwemdimtapsar@jbohm.dk> writes:
[...]

I am unsure how GCC --pedantic deals with the standards-contrary
features in the GNUC89 language, such as the different type of (foo,
'C') (GNUC says char, C89 says int), maybe specifying standard C
instead of GNUC reverts those to the standard definition .

I'm not sure what you're referring to. You didn't say what foo is.

I believe that in all versions of C, the result of a comma operator has
the type and value of its right operand, and the type of an unprefixed character constant is int.

Can you show a complete example where `sizeof (foo, 'C')` yields
sizeof (int) in any version of GNUC?

Presumably that's a typo - you meant to ask when the size is /not/ the
size of "int" ? After all, you said yourself that "(foo, 'C')"
evaluates to 'C' which is of type "int". It would be very interesting
if Jakob can show an example where gcc treats the expression as any
other type than "int".


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

David Brown <david.brown@hesbynett.no> writes:

On 18.08.2025 07:18, Keith Thompson wrote:

Jakob Bohm <egenagwemdimtapsar@jbohm.dk> writes:
[...]

I am unsure how GCC --pedantic deals with the standards-contrary
features in the GNUC89 language, such as the different type of (foo,
'C') (GNUC says char, C89 says int), maybe specifying standard C
instead of GNUC reverts those to the standard definition .

I'm not sure what you're referring to. You didn't say what foo is.
I believe that in all versions of C, the result of a comma operator
has
the type and value of its right operand, and the type of an unprefixed
character constant is int.
Can you show a complete example where `sizeof (foo, 'C')` yields
sizeof (int) in any version of GNUC?

Presumably that's a typo - you meant to ask when the size is /not/ the
size of "int" ? After all, you said yourself that "(foo, 'C')"
evaluates to 'C' which is of type "int". It would be very interesting
if Jakob can show an example where gcc treats the expression as any
other type than "int".

Yes (more of a thinko, actually).

I meant to ask about `sizeof (foo, 'C')` yielding a value *other than*
`sizeof (int)`. Jakob implies a difference in this area between GNU C
and ISO C. I'm not aware of any.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.21a-Linux NewsLink 1.2