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

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

On 2024-09-09, David Brown <david.brown@hesbynett.no> wrote:

On 09/09/2024 20:46, Kaz Kylheku wrote:

On 2024-09-09, David Brown <david.brown@hesbynett.no> wrote:

On 09/09/2024 18:57, Bart wrote:

On 09/09/2024 17:21, Waldek Hebisch wrote:

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

>

C23 doesn't add any new support for 128-bit integers.

>
So what does _Bitint do with a width of 128 bits?
>

>
_BitInt types are not "integer types".  Nor is gcc's __int128 type.

 
How can we write a program which, in an implementation which has a
__int128 type, outputs "yes" if it is an integer type, otherwise "no"?
 

>
#include <stdio.h>
>
int main() {
     auto const x = 0x1'0000'0000'0000'0000;
     if (x > 0xffff'ffff'ffff'ffff) {
         printf("yes\n");
     } else {
         printf("no\n");
     }
}

>
If the constant in this program is too wide for any integer type, that
is a constraint violation requiring a diagnostic.  After that, if the
program is translated or executed anyway, the behavior is undefined.
>
I'd like the program to have well-defined behavior, under the
test assumption (that a documented, conforming extension is provided
in the form of __int128).
>
If the implementation were to truncate the constant to 64 bits, and then
choose a 64 bit type for x, then we would expect the "no" output; but
that doesn't show that there __int128 isn't an integer type, only that
the type is not equipped with constants.
 
Integer types don't have to have their own matching constants. The types
char and short don't have their own constants; they borrow int.
Library support can be missing, in regard to formatting __int128 to
text and back.
>
The __int128 type better support all integer arithmetic, though: and
there should be conversion rules regarding when __int128 is opposite to
an operand of a different type. An __int128 should be usable as a
displacement in pointer arithmetic. It should be possible to switch() on
an __int128, even if a constant cannot be expressed for every possible
value.

I had thought that the standard required support for constants of
extended integer types wider than int, but the wording seems ambiguous
at best.

An unsuffixed decimal constant, for example, has a type that is the
first of int, long int, long long int in which its value can be
represented.  But:

    If an integer constant cannot be represented by any type in its
    list, it may have an extended integer type, if the extended
    integer type can represent its value. If all of the types in
    the list for the constant are signed, the extended integer type
    shall be signed. If all of the types in the list for the constant
    are unsigned, the extended integer type shall be unsigned. If
    the list contains both signed and unsigned types, the extended
    integer type may be signed or unsigned. If an integer constant
    cannot be represented by any type in its list and has no extended
    integer type, then the integer constant has no type.

The word "may" in that first sentence seems problematic.  It implies a
choice: either a decimal integer constant with a value of LLONG_MAX+1 is
of an extended integer type, or it isn't.  One possible interpretation
is that such a constant must be of an extended integer type if an
appropriate type exists.  Another is that it may or may not be of an
extended integer type at the whim of the implementation -- but the
standard doesn't say that the choice is either implementation-defined or
unspecified.  It just says "may".

GCC's documentation specifically states that "GCC does not support any
extended integer types" and that __int128 is an extension.  The
documentation refers to it as an "integer scalar type" (but apparently
it's not an integer type as that term is used in the standard).  It says
there are no constants of type __int128 for targets with long long less
than 128 bits wide, but it doesn't say that that's why it's not an
extended integer type.  (Does gcc support any targets with long long
wider than 64 bits, or is that wording just there to cover possible
future implementations?)

If gcc treated __int128 as an extended integer type, a gcc-based
implementation would have to make intmax_t 128 bits.  That would cause
some serious ABI issues, and is likely why __int128 isn't treated as an
extended integer type.

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