Re: "C" compiler where 0 is not of type int?

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.