Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: sizeof Data types Date: Tue, 09 Aug 2016 08:12:23 -0700 Organization: None to speak of Lines: 50 Message-ID: References: <4ccb69e9-3af1-4bf7-8893-773508c03bf9@googlegroups.com> <450a4877-bb68-48d5-b24e-123ca59569a1@googlegroups.com> <433a7e7e-5f86-4a08-864f-f6074bf53cc8@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="945944de09706c9b4e29b53c9d2efdc2"; logging-data="3251"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1889WjsO2ivCwb+oISM60tP" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:9uBODoqvaFXcAWk/Hd11S3Ed+9E= sha1:zDOr0NyakPif0XTDumqp2eRD6hI= Xref: csiph.com comp.lang.c:92016 David Brown writes: > On 08/08/16 23:09, supercat@casperkitty.com wrote: >> On Monday, August 8, 2016 at 12:05:44 PM UTC-5, David Brown wrote: >>> If you don't want implementation dependent behaviour in your programs, >>> don't write code that depends on the implementation. >>> >>> int diffcomp(uint16_t a, uint16_b, uint16_t c) { >>> return (unsigned int) a - b > c; >>> } >> >> The effect of that will still vary depending upon the implementation. > > Perhaps I have got the details wrong, but my understanding here is: > > uint16_t is either "unsigned short", "unsigned int", or an unsigned > extended integer type of lower rank than "unsigned int". It could also be unsigned char if CHAR_BIT==16. That doesn't affect the rest of the discussion. [...] > But your example is an extremely hypothetical one. First, 64-bit int > systems are rare - the only one I have heard of is some early Cray > systems, and they also had 64-bit short (and therefore no uint32_t). > Secondly, /if/ you were writing such modular arithmetic routines that > had to be portable even to the Cray, you would use separate functions > rather than casting. You would probably also not rely on the existence > of uint32_t, but rather use "unsigned long" and explicit modulos for > greater portability. Cray vector systems such as the T90 and the more recent SV1 have 64-bit short, int, and long. Some other Cray systems, such as the Alpha-based T3E, have 32-bit short and 64-bit int and long. When I worked on them, there was no C99 compiler, and I don't *think* there was a or header. Systems with 64-bit int are rare today, largely because making int 64 bits means you can't have 8-bit, 16-bit, 32-bit, and 64-bit integer types without using extended integer types, and probably because the size of int is imposed by the ABI. But I wouldn't assume that will continue to be the case. [...] -- Keith Thompson (The_Other_Keith) kst-u@mib.org Working, but not speaking, for JetHead Development, Inc. "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"