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.

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

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.

Or it might be that the compiler was a pre-ANSI-standard compiler,
where a "non-conforming" label has no meaning.

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?

Even if there were a C compiler where 0 has a type other than
int, it seems unlikely that the cast would be necessary. I
haven't bothered to check, but my recollection is that even
K&R C allowed assignment between different numerical types.
And surely every numerical type includes a representation
for the abstract value 0.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)