Re: Top 10 most common hard skills listed on resumes...

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