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: mergesort code segfaulting on smallish arrays Date: Sun, 10 Nov 2019 14:30:53 -0800 Organization: None to speak of Lines: 77 Message-ID: References: <87mud63p3b.fsf@bsb.me.uk> <%QBxF.59077$VR.21809@fx39.iad> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="f377008cb6eca49df502c940167c0c6d"; logging-data="19804"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+GHxcqGEfeyMG/dbUXds+e" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:4mdli+mOnoMjNVNLEuWQThcaERE= sha1:QFq9w1NZVee46w0ivS/BNIYV5JE= Xref: csiph.com comp.lang.c:147929 David Brown writes: > On 09/11/2019 18:21, Richard Damon wrote: [...] > I believe some Cray systems used 64-bit for short, int and long. (That > is based entirely on reading on the web, not on any personal experience.) Yes, I mentioned it here yesterday. >> By the straight reading of the language, >> on 64 bit processors, int should have been 64 bits, and long 128 bits. >> The fact that it would leave a hole in the type system, with no natural >> name for both 16 and 32 bit types provided a push to make int 'too >> small' for the machine at 32 bits. (It also helped that much code >> mistakenly assumes int is 32 bits and that the processors handle 32 bit >> ints well). >> >> My guess is that if/when we get to 128 bit processors, there may well be >> a need for int to grow up to 64 (or even 128 bits) and we will add types >> like short short (and maybe even long short). The language might also >> evolve to assume the 8-bit byte and make the fixed sized types the >> natural types. >> > > I suspect that is unlikely. Sizes are ingrained in peoples' minds, > regardless of what the standard says. And 8-bit char, 16-bit short and > 32-bit int is very convenient, and will continue to be very convenient > even if processors start handling 128 bit sizes more efficiently. The > number of uses of integers that are bigger than 32-bit is quiet small, > and the cache miss ratio costs of 64-bit int would be high. Most > integer usage bigger than 32-bit is in sizes of data in memory or file, > and 64-bit is going to cover that for a long time. How often do you > have need of an integer type that is bigger than 64-bit, but where > 128-bit is really helpful? If you are moving data around, or doing > cryptography, hashes, etc., you really want a lot bigger than 128-bit. > > Of course, any prediction of "this should be big enough for anyone" is > going to be wrong :-) It occurs to me that there are (at least) two characteristics that make int special relative to the other built-in integer types. One is that it "has the natural size suggested by the architecture of the execution environment". This is vague enough to leave room for most implementations to have 32-bit int on most 64-bit systems, even though it's easy to argue that 64-bit int would be more "natural". Another is that it's the type to which narrower types are promoted. The assumption is that there are no arithmethic operations on integer types narrower than int or unsigned int. But most modern 64-bit systems have hardware support for 32-bit and 64-bit arithmetic. A C implementation with 64-bit int would have no explicit support for 32-bit arithmetic operations. Given 32-bit short and 64-bit int, this: short s = 42; s++; would logically convert s from short to int, add 1 to it, and convert back to short. Of course a compiler could optimize this by using a 32-bit add or increment instruction -- but only if it can prove that the results will be the same in all cases where the behavior is defined. This special property of int (and unsigned int) causes some problems for the fixed-width types. The behaviors of int16_t, int32_t, and int64_t can be quite different in some cases depending on the width of int. It doesn't matter (I think) for cases where all operands and results are within range, but it can make a significant difference for some corner cases. I'd be happier if int and unsigned int *didn't* have this special property, and for narrower and wide integer types to behave more uniformly, but I don't know if it would be possible to change it without breaking existing code. -- Keith Thompson (The_Other_Keith) kst-u@mib.org Working, but not speaking, for Philips Healthcare void Void(void) { Void(); } /* The recursive call of the void */