Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
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: <v7ai37$2ak85$2@dont-email.me>
References: <87ikx3h050.fsf@nosuchdomain.example.com>
 <bc98559c10d4a52c653a6fb04e23035309b9720b@i2pn2.org>
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: <bc98559c10d4a52c653a6fb04e23035309b9720b@i2pn2.org>
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.