Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: Sort char array Date: Sat, 12 Oct 2019 12:17:58 -0700 Organization: None to speak of Lines: 66 Message-ID: References: <20191007131948.c9f28d44bcd105e7a153069a@g{oogle}mail.com> <2xFmF.867378$yH4.431562@fx18.am4> <20191007174244.385138503569a8bc6d4eec9d@g{oogle}mail.com> <20191008022725.36fbd95aa45ba185290e5e11@gmail.com> <1q_mF.841756$Zy3.585129@fx33.am4> <20191009020207.b533aa1c6d95f44eb314ffc1@gmail.com> <5alnF.1041354$WI2.353384@fx34.am4> <5b525fc7-aeb6-47ec-b425-526a60d31e92@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="e7dcfb9e050a69901d7f41fe98f66f92"; logging-data="8664"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/LxFWUlU2IyGUfSvT11ZBZ" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:npl7kyoWDKo8CxynEfIpsueDPgI= sha1:VXbMzFmIKNEytaUsgY5HYsuJpjs= Xref: csiph.com comp.lang.c:146899 David Brown writes: > On 11/10/2019 20:16, Keith Thompson wrote: >> James Kuyper writes: >> [...] >>> You should be able to count on any implementation that supports a >>> 128-bit 2's complement type with no padding bits, to support int128_t as >>> a typedef for that type. Unfortunately, I've been informed that this is >>> not the case, but that is cause for complaint to the implementer, not to >>> the committee. >> >> The problem with that is that intmax_t would then have to be at least >> 128 bits. There are ABIs that would break if the size of intmax_t >> (currently 64 bits on most systems) were changed. Thus __int128 is >> a gcc extension and is *not* classified as a standard or extended >> integer type. > > I think (but I am not sure) that making an "int128_t" extended integer > type also requires the implementation to support constants of that > type, and to support PRId128 and similar macros with corresponding > support in functions like printf. This would mean significant > amount of work for features that would be of relatively little use. A conforming C implementation *that doesn't have to worry about backward compatibility* could have 64-bit long long, make int128_t a typedef for an extended integer type, and make intmax_t a typedef for that same extended integer type. (The problem with such an implementation is that it would break compatibility with existing libraries that assume intmax_t is 64 bits.) I don't see a requirement in the standard to support constants of type int128_t. But an implementation could support such constants as an extension. (gcc doesn't.) >> Which is a great pity IMHO. > > Perhaps it would be possible to introduce some limited form of > extended integer type in a standardised way? Then you could allow, > say, "_int128_t" to function as an integer type with regard to > arithmetic without imposing additional requirements. This would > correspond to gcc's "__int128", and could be standardised. It might be possible, but I'd probably oppose it. gcc's __int128 is a bit of a hack, providing *partial* support for 128-bit integers. I'd like to see full (optional) support for 128-bit integers as integer types. That would require a solution to the intmax_t problem, and I'm not at all sure what such a solution would look like. There are existing implementations that don't support 128-bit integers in any way, and we need to continue supporting them (unless we want to make 128-bit integers mandatory, as C99 made 64-bit integers mandatory). On my system (Ubuntu 18.04.3), I already have at least three sets of libraries for different memory models: gcc -m64, gcc -m32, gcc -mx32. Adding optional support for 128-bit intmax_t would require at least one more set of libraries, with different implementations of printf and other functions. Maybe that's the way to go, but it would be nice to avoid potentially exponential growth of standard library implementations. At this point, I suspect there just isn't enough demand for 128-bit integers to justify a full solution. -- Keith Thompson (The_Other_Keith) kst-u@mib.org Will write code for food. void Void(void) { Void(); } /* The recursive call of the void */