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: Sun, 10 May 2026 18:37:39 -0700 Organization: A noiseless patient Spider Lines: 43 Message-ID: <86o6imrajg.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> <10tr275$nak7$1@dont-email.me> <10tr3q0$nuak$1@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Date: Mon, 11 May 2026 01:37:40 +0000 (UTC) Injection-Info: dont-email.me; logging-data="834501"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18sdLuPjQ4vbEZlHrqSx4aNoNJyHjXOK0Y="; posting-host="e12ff559fd79fb3307443db8d47ea871" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:L8TeTkdoXpmrTxFuMYYMlfA6tLM= sha1:XGE/EOuO5u+PHObGXEk5CtAHHGo= sha256:cPQ+aHK2TQW/tCczk/7r7ry8IKeMyicfLzLFqDt5XiQ= sha1:oTpogVGL1UZIvH8dJPOfQS6ouhM= Xref: csiph.com comp.lang.c:398695 kalevi@kolttonen.fi (Kalevi Kolttonen) writes: > James Kuyper wrote: > >> On 2026-05-10 16:15, Kalevi Kolttonen wrote: >> >>> 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? >> >> If uint8_t exists, CHAR_BIT must be 8, and unsigned char must therefore >> meet the requirements to be the type that uint8_t is a typedef for. >> However, the standard doesn't mandate it. If, for example, a machine >> supported two different 8-bit types, with the order of the bits from low >> to high reversed between them, uint8_t could be one of those types, and >> unsigned char could be the other - the C standard imposes no >> requirements that would be broken by that choice. >> This is not something you're likely to ever see, just a possibility >> allowed by the standard that we're extremely unlikely to see. > > I see, thanks. So from a practical point of view today, they > appear pretty identical. The possibility of differing representations had no bearing on my comment. In most cases two types[*] whose representations happen to be different can be used interchangeably. ([*] of the same width and signedness, of course.) The key point is that unsigned char and uint8_t can be distinct types even when they have the same representation. Where this matters is when a pointer is needed to one type or the other. If for example there is a function with a parameter whose type is unsigned char *, it doesn't do to take the address of a uint8_t to supply as the argument, and vice versa. It's easy to imagine that an implementation could choose to make uint8_t be a type distinct from unsigned char, in the interest of type safety. Thus one case where I would choose uint8_t is where there is an externally defined library function with a uint8_t * parameter. I don't remember ever seeing that, but if it came up that would be a reason to use uint8_t rather than unsigned char.