Path: ...!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <Keith.S.Thompson+u@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: Top 10 most common hard skills listed on resumes...
Date: Tue, 10 Sep 2024 12:18:41 -0700
Organization: None to speak of
Lines: 56
Message-ID: <875xr31fn2.fsf@nosuchdomain.example.com>
References: <vab101$3er$1@reader1.panix.com> <vbcs65$eabn$1@dont-email.me>
	<vbekut$1kd24$1@paganini.bofh.team> <vbepcb$q6p2$1@dont-email.me>
	<vbgb5q$1ruv8$1@paganini.bofh.team> <vbhbbb$1blt4$1@dont-email.me>
	<vbipp5$24kl5$1@paganini.bofh.team> <vbk0d9$1tajm$1@dont-email.me>
	<vbkpfc$27l2o$1@paganini.bofh.team> <vbl3am$228vv$1@dont-email.me>
	<vblfgb$2dkij$1@paganini.bofh.team>
	<878qw13a40.fsf@nosuchdomain.example.com>
	<vbll6l$2dpn7$2@paganini.bofh.team>
	<874j6p34df.fsf@nosuchdomain.example.com>
	<vbn79l$2g9i6$1@paganini.bofh.team> <vbn9e1$2fqep$1@dont-email.me>
	<vbnboc$2g0vc$2@dont-email.me> <20240909114553.226@kylheku.com>
	<vbngrb$2gvrs$1@dont-email.me>
	<87v7z41t1m.fsf@nosuchdomain.example.com>
	<vboruc$2qqt1$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Date: Tue, 10 Sep 2024 21:18:46 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="29df7bbfeaa4d6ddeb7fdca1349b4e93";
	logging-data="3288061"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18kZ+rDnrCIVLZM7Zw2mA5B"
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:fevDixbZ6ZvOnars6QlMdu/Zu5w=
	sha1:uX6FAepfRbM+lyJ8w+LE0dmV9ok=
Bytes: 4031

David Brown <david.brown@hesbynett.no> writes:
> On 09/09/2024 22:16, Keith Thompson wrote:
[...]
> I felt free to use C23 because we were already talking about the
> support, or lack thereof, of 128-bit integers in C23, and also
> _BitInt. And on a platform that supported 128-bit integer types,
> "auto" would pick a 128-bit type here, while other platforms would
> pick a 64-bit type.

That last assumption turns out not to be correct.

>> If an implementation doesn't have an integer type wider than 64 bits,
>> then the constant 0x1'0000'0000'0000'0000 has no type, which violates
>> a constraint.
>
> Indeed.  Conforming implementations need to give an error or warning
> here.  But some will also then map it to a 64-bit value (I'd usually
> expect 0, but 0xffff'ffff or 0x7fff'ffff might also be used) and
> continue compilation.  That gives a program with the desired
> behaviour. (For my own uses, I would pick flags that gave an error on
> such code.)

gcc 14.2.0 gives it type int and value 0.  I think what's happening is
that the value wraps around, and then the compiler determines its type
based on that.  It also issues a warning.

Since the code violates a constraint, you can't rely on its behavior.

clang 18.1.0 rejects it.

>> If an implementation does have a integer types wider than 64 bits,
>> there's no guarantee that it uses the name "__int128".  A future gcc
>> might have a 128-bit (extended) integer type and still have __int128
>> with its current semantics.
>
> If an implementation had a standard integer type of 128 bits, then I
> expect "long long int" would be the name (unless it also had even
> bigger types!), but for extended integer types it could be many
> different things.  It is very likely, however, that it would also be
> in <stdint.h> as int128_t.

I would probably expect most compilers to keep long long at 64 bits, to
cater to existing code that makes that assumption.  That's what gcc did
when it added __int128 (which is *almost* an extended integer type, but
they don't call it one).

> Do you know of any implementations that do have 128-bit integer types?
> In particular, any that have a compiler on godbolt.org?

None that I know of.

[...]

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */