Path: csiph.com!eternal-september.org!feeder.eternal-september.org!nntp.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: Safety of casting from 'long' to 'int' Date: Tue, 12 May 2026 20:47:59 -0700 Organization: A noiseless patient Spider Lines: 71 Message-ID: <86pl30km1c.fsf@linuxsc.com> References: <10su8cn$am9i$1@dont-email.me> <10tls2u$39j7a$1@dont-email.me> <10tm49i$9d$1@reader1.panix.com> <10tn3so$3j8hc$1@dont-email.me> <10tnj8s$pnq$1@reader1.panix.com> <10tnmk6$3os5b$1@dont-email.me> <10tnnv1$3o0n8$2@dont-email.me> <10tntu0$3r6q3$1@dont-email.me> <865x4vrqgu.fsf@linuxsc.com> <10tqp0l$ktbv$1@dont-email.me> <861pfiq8xc.fsf@linuxsc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Date: Wed, 13 May 2026 03:48:00 +0000 (UTC) Injection-Info: dont-email.me; logging-data="2557305"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+o3+a3QlTNa1wc6mfZaI3Ugadn8MO5Kt8="; posting-host="ace8b6eaa328dcf44f89a3207699c4cb" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:5rMjaEL688m/Csd4gOoQgtWT/w4= sha1:97+8NJHoZDtu4lwxnCN8ViiNjTI= sha256:/aifjrOckERZulG0Ud2Md4Dw6To7aqUEXJ8YArRFJVw= sha1:P9g0WzXtZkaVVkF+OMoLyTkvt74= Xref: csiph.com comp.lang.c:398841 scott@slp53.sl.home (Scott Lurndal) writes: > Tim Rentsch writes: > >> scott@slp53.sl.home (Scott Lurndal) writes: >> >>> kalevi@kolttonen.fi (Kalevi Kolttonen) writes: >>> >>>> Tim Rentsch wrote: >>>> >>>>> In almost all cases where uint8_t >>>>> might be used, unsigned char works just as well. >>>> >>>> Why "almost"? Where is the difference if any? >>>> >>>> As far as I know, ISO guarantees that >>>> sizeof(unsigned char) is always 1 byte. >>> >>> On at least one system with a working C compiler, >>> a byte is 9 bits, not 8. If I wanted an 8-bit datum >>> on that system, I'd have to use uint8_t. >> >> If a byte is 9 bits (ie, if CHAR_BIT == 9) there cannot >> be a uint8_t type. The fixed-width types are not allowed >> to have padding bits. > > That was a 36-bit system. It could easly create a > uint8_t value from 1/9th of two 72-bit words; > so no padding bits required. That doesn't work in C where CHAR_BIT == 9, which I think other people have explained. There could be a uint9_t in such an environment, but not uint8_t because the fixed-width types are not allowed to have padding bits; all objects other than bit-fields are mandated to have a whole number of bytes (which in C is the same size as the character types), so an 8-bit integer type with no padding bits isn't possible. >>> Indeed. Although from my perspective, the use of the >>> stdint types clearly documents the programmers >>> intent, whereas a typedef such as BYTE or WORD >>> is inherently ambiguous and would require a programmer >>> to look up the definition of such types in the >>> application to determine the original programmers intent. >> >> BYTE and WORD are poor choices for type names, no doubt >> about that. On the other hand, in many or most cases >> so are [u]intNN_t; they simultaneously convey both too >> little and too much information. There is a certain kind >> of programming where the fixed-width types are genuinely >> helpful; unfortunately though they are used a lot more >> widely than circumstances where they are helpful. > > The programming I do > (mainly kernel programming, SoC simulation, > firmware) all naturally require the fixed-width types. Right. Code that interacts very closely with hardware is one of those cases where the fixed-width types make sense. > For other apps, int, long, float, double are preferred > to INT, LONG, FLOAT, DOUBLE (which seems to be the > way windows programmers code)[*] > > [*] which probably dates back to 16-bit windows > and their methods of maintaining backward compatability > across two subsequent (32, 64) x86 processor architectures > plus MIPS et alia. I wouldn't hold Microsoft Windows code up as an example for anyone except perhaps as a horror story. :)