Path: ...!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c
Subject: Re: Top 10 most common hard skills listed on resumes...
Date: Tue, 10 Sep 2024 22:10:24 +0200
Organization: A noiseless patient Spider
Lines: 80
Message-ID: <vbq93g$34rfb$1@dont-email.me>
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> <875xr31fn2.fsf@nosuchdomain.example.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 10 Sep 2024 22:10:25 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="0acb7c652597723591106fbd8bd9fb14";
	logging-data="3304939"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX199RzEoMv7fOk1OIflcXjlO7jiIUbcF2to="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:7GTd4FlDWqxacvt5N9ogOwbdMlA=
In-Reply-To: <875xr31fn2.fsf@nosuchdomain.example.com>
Content-Language: en-GB
Bytes: 5252

On 10/09/2024 21:18, Keith Thompson wrote:
> 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.

I don't know of a platform that has 128-bit integers, so I haven't 
tested it.  But I agree with you that it is not quite clear what the 
standard requires if an implementation has 128 bit integers as an 
extended integer type, rather than a standard integer type.

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

(I was missing a few ffff's here.)

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

My code was the best I could do that looked like it would give the 
required behaviour - at least on some platforms.  It is plausible that 
gcc documents that behaviour somewhere (though I have not seen such 
documentation myself), which would make it non-portable but reliable for 
that compiler - even in conforming modes.  I don't see any way to get 
closer to the requested behaviour in a way that would also work on a 
hypothetical 128-bit integer target.

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

It seems likely, but it is not the only possibility.  For platforms that 
have 64-bit "long", a 128-bit "long long" is not unreasonable.

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

I believe there is a specification for a 128-bit RISC-V version, but no 
implementation in practice, and no version of gcc for it (at least, not 
in mainline gcc).