Path: ...!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: Top 10 most common hard skills listed on resumes... Date: Tue, 10 Sep 2024 04:19:46 -0700 Organization: A noiseless patient Spider Lines: 53 Message-ID: <86bk0viwml.fsf@linuxsc.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; charset=us-ascii Injection-Date: Tue, 10 Sep 2024 13:19:49 +0200 (CEST) Injection-Info: dont-email.me; posting-host="2716f454c4dece03d014ce5d7a2dd1ff"; logging-data="3087984"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18KEKv0RWWosgHrrDnCUoXYhvIOIGz8Jsk=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:TSXFtrb3j9Ll9OW76r5yZoX4KS0= sha1:AKXn4ZrGurOkzDQJ0midi1Z+/ao= Bytes: 3991 Kaz Kylheku <643-408-1753@kylheku.com> writes: [edited for brevity] >>> 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"? > > 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). > > 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. To clarify, what you want is (I think) an integer-like type, not necessarily an extended integer type. As long as expressions and values having the type in question behave like other expressions and values of integer types (as the C standard uses the term), it's all good. Something that I think you want but isn't mentioned is casting: you want to be able to use explicit conversions (in other words, casts) to force values or subexpressions to take on the new type. As long as the regular arithmetic operations works and casting works, and like you say switch() works with the new type, then switch() statements are available, because 'case' needs only an integer constant expression, and is not limited to constants. Assuming all that is right, I recommend typedef __uint128_t U128; typedef __int128_t S128; which works in both gcc and clang (I don't know yet about Visual Studio). (Let me add parenthetically that I don't see why you want the program described. Just put those typedefs in your code, and if compiling the code barfs then you know they aren't supported. On platforms where those particular names are not supported but other ways of supplying the types are, using a #define or two might rescue the situation (and the #define's can be #undef'ed after the typedef statements are processed).)