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: Mon, 11 May 2026 08:10:07 -0700 Organization: A noiseless patient Spider Lines: 44 Message-ID: <861pfiq8xc.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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Date: Mon, 11 May 2026 15:10:08 +0000 (UTC) Injection-Info: dont-email.me; logging-data="1262179"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+EigKhQPV2D6TyGVzLXyvlLslPbbNG0Ck="; posting-host="e12ff559fd79fb3307443db8d47ea871" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:gTXPrt7xY9oj2tnft06QHkhuek4= sha1:QmlKreLVd/8iRPE88I1R1yM7brY= sha256:v0ZSPYhCSekrDVRFOK/wFGOmuw0zHrS5TPe8tbMbADU= sha1:bFnQ4wivuS0MVnVkpnRFHjLrWao= Xref: csiph.com comp.lang.c:398724 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. > (Now, I haven't used that system in decades, but it > still exists and powers a large fraction of the > worlds airline reservation and operational functions). > >> And operations on unsigned char are well defined, >> including wrap-around. So I fail to see any >> difference between unsigned char and uint8_t. > > 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.