Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: David Brown Newsgroups: comp.lang.c Subject: Re: "C" compiler where 0 is not of type int? Date: Thu, 18 Jul 2024 10:00:39 +0200 Organization: A noiseless patient Spider Lines: 73 Message-ID: References: <87ikx3h050.fsf@nosuchdomain.example.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Thu, 18 Jul 2024 10:00:40 +0200 (CEST) Injection-Info: dont-email.me; posting-host="5e58e10ba9a4731c305671ca05dd8458"; logging-data="2445573"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19DIuAZtSGUoqWIdQiypllAAX2gKjMBUtQ=" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Cancel-Lock: sha1:rzEjm4YtaS4J5rxoUZ0MneADlIc= Content-Language: en-GB In-Reply-To: Bytes: 4460 On 18/07/2024 05:35, Richard Damon wrote: > On 7/17/24 11:03 PM, Keith Thompson wrote: >> This is going to sound like an odd question, because it is. >> >> I saw this code fragment in an answer posted on Quora: >> >>      // In case literal 0 isn't an int on this platform. >>      int z = (int) 0; >> >> The writer encountered this in an old C project, and suggested that the >> author of the code might have had a legitimate concern.  (He ended up >> removing the cast.) >> >> Obviously 0 is of type int in every C standard.  If the cast were >> necessary, it would be because of a non-conforming compiler. >> >> I've heard of non-conforming C compilers that make int 8 bits, or that >> don't have long double, or that have a long double type that doesn't >> meet the standard's range and/or precision requirements. >> >> My question is this: Has there ever been a (non-conforming) C compiler >> that gave a constant 0 a type other than int? >> >> (I'm ignoring the use of a "//" comment; the writer may not have copied >> the code verbatim.) >> > > I thought I remembered a compiler for a small processor that didn't > promote smaller than ints to int to do the arithmatic because full int > arithmetic was expensive, even for just 16 bits, as the processor only > worked 8 bits at a time. > There have certainly been C (or "C", if you prefer) compilers that work that way. I have used at least one such tool, though only briefly - it was very annoying. Most modern 8-bit C compilers do the right thing and promote to int as required, and then eliminate the extra work as an optimisation if the result is assigned to an 8-bit type. I'd expect "0" to be an int on such compilers, but it is not a detail I knew at the time, and I have no easy way to check it now. The assignment "int z = 0;" would surely convert whatever type 0 is into an "int" anyway. The AVR port of gcc has a flag "-mint8" that makes "int" 8 bits. This is, of course, non-conforming, but it means there are never any other promotions (except _Bool to int). I don't think it is much used except on the very smallest of target devices - if you only have 2K or 4K of code flash, you want to save every byte you can and you also have full control of all your code so that you can check it is "8-bit int" safe. > Small literal values might have been considered of type char, but even > on that system, the assignement would have promoted the small value so > the cast wouldn't have been needed. Indeed. However, there have certainly been compilers for embedded devices that are buggy, limited, and non-conforming in all sorts of imaginative ways. I've come across tools that did not zero-initialise uninitialised static lifetime data (that caused a /lot/ of "fun" in debugging until I figured out this behaviour). In portable embedded C code it is not uncommon to see explicit initialisation to 0 to handle such tools, even though the result is less efficient for most compilers. It is conceivable that there have been compilers that treated "0" as 8 bits and only clear 8 bits of the "int z" on the assignment. I think it is quite unlikely, but not impossible, especially as a compiler bug rather than a misfeature.