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: Wed, 13 May 2026 11:00:58 -0700 Organization: A noiseless patient Spider Lines: 52 Message-ID: <86v7crjijp.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> <10tt6u4$1adha$6@kst.eternal-september.org> <86h5oblg91.fsf@linuxsc.com> <10u1nlo$1l93k$16@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Date: Wed, 13 May 2026 18:00:59 +0000 (UTC) Injection-Info: dont-email.me; logging-data="3026765"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+LRu3jg84QQ3KP5hZ3TbsqCd0032pmHKA="; posting-host="ace8b6eaa328dcf44f89a3207699c4cb" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:eWQEOmfwu2hrwS3+pzbUnvHtFxI= sha1:CoCUWrOcG62CfThfSj36hP2RIjs= sha256:pNIAyZFPoBj4BXeDZzPOV6FUzMWdNDgyDJC7tlKA9UY= sha1:TxdTCA9pqBGay7KXHbzmSVEh6yg= Xref: csiph.com comp.lang.c:398892 Janis Papanagnou writes: > On 2026-05-13 13:07, Tim Rentsch wrote: > >> Keith Thompson writes: >> >>> Tim Rentsch writes: >>> [...] >>> >>>> BYTE and WORD are poor choices for type names, no doubt >>>> about that. >>> >>> [...] >>> >>> WORD is certainly ambiguous (unless, I suppose, it's sufficiently >>> obvious from the context). But I don't have a problem with BYTE, >>> or preferably byte, as a type name as long as it really is a byte. >>> >>> [...] >> >> BYTE is a poor choice for a type name because it looks like a >> macro. >> >> A lower-case version, byte, is a poor choice for a type name, >> because it is both confusing and ambiguous. >> >> Confusing, because for a very long time and for a huge segment of >> the programming community, the term byte is synonymous with eight >> bits, but in C that need not be true. > > Actually, it was more an issue in the "intermediate epoch", when > terminology spread to the non-expert home-users who considered > a byte to be 8 bit on their typical PC systems while not knowing > anything from the professional IT world before (with 6, 7, 9 bit > entities). Nowadays I'd consider it less an issue since these > systems seem to have (mostly?) vanished. There was a reason why > the standards back then introduced and used the term "octet" for > the common 8-bit entities, to avoid ambiguity and misunderstanding. > > What's technically defined for the "C" language in the respective > standard documents is an own thing, not necessarily equivalent to > the respective application semantics expressed by some C-program, > although I'd always prefer "octet" for that (and avoid "byte"). I agree with your comment about preferring "octet", but let me add to that. There is another difference worth noting. A byte is a unit of storage, whereas octet is a measure of information. The word byte is inherently about memory; the word octet is inherently about value (eight bits of information). For this reason too the name 'octet' is a better choice for a type name than 'byte'.