Path: ...!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: Top 10 most common hard skills listed on resumes... Date: Mon, 09 Sep 2024 16:24:08 -0700 Organization: None to speak of Lines: 101 Message-ID: <87r09s1kdj.fsf@nosuchdomain.example.com> References: <878qw13a40.fsf@nosuchdomain.example.com> <874j6p34df.fsf@nosuchdomain.example.com> <20240909114553.226@kylheku.com> <20240909152336.398@kylheku.com> MIME-Version: 1.0 Content-Type: text/plain Injection-Date: Tue, 10 Sep 2024 01:24:09 +0200 (CEST) Injection-Info: dont-email.me; posting-host="29df7bbfeaa4d6ddeb7fdca1349b4e93"; logging-data="2700065"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19PQY/QSg0+w08EWq4xHdeJ" User-Agent: Gnus/5.13 (Gnus v5.13) Cancel-Lock: sha1:Yqmt+DQlntlld8ofwQtZtIQWLyc= sha1:ZBMWGAptf6OlsPwbqjiOnnWH3oU= Bytes: 6340 Kaz Kylheku <643-408-1753@kylheku.com> writes: > On 2024-09-09, David Brown wrote: >> On 09/09/2024 20:46, Kaz Kylheku wrote: >>> On 2024-09-09, David Brown wrote: >>>> On 09/09/2024 18:57, Bart wrote: >>>>> On 09/09/2024 17:21, Waldek Hebisch wrote: >>>>>> Keith Thompson 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 >> >> 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 */