Path: ...!weretis.net!feeder9.news.weretis.net!panix!.POSTED.spitfire.i.gajendra.net!not-for-mail
From: cross@spitfire.i.gajendra.net (Dan Cross)
Newsgroups: comp.unix.programmer
Subject: Re: Command Languages Versus Programming Languages
Date: Fri, 22 Nov 2024 22:34:52 -0000 (UTC)
Organization: PANIX Public Access Internet and UNIX, NYC
Message-ID: <vhr0uc$656$1@reader2.panix.com>
References: <uu54la$3su5b$6@dont-email.me> <87cyinthjk.fsf@doppelsaurus.mobileactivedefense.com> <vhqs7k$btv$1@reader2.panix.com> <e47664d3-7f9b-4e67-aa73-b72c6cc0687a@alumni.caltech.edu>
Injection-Date: Fri, 22 Nov 2024 22:34:52 -0000 (UTC)
Injection-Info: reader2.panix.com; posting-host="spitfire.i.gajendra.net:166.84.136.80";
	logging-data="6310"; mail-complaints-to="abuse@panix.com"
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
Originator: cross@spitfire.i.gajendra.net (Dan Cross)
Bytes: 2507
Lines: 38

In article <e47664d3-7f9b-4e67-aa73-b72c6cc0687a@alumni.caltech.edu>,
James Kuyper  <jameskuyper@alumni.caltech.edu> wrote:
>On 11/22/24 16:14, Dan Cross wrote:
>...
>> irrelevant.  That's not how C works: C will promote those
>> `unsigned char` values to `signed int` before it does the
>> subtraction.  It does this because `unsigned char` has _rank_
>> lower than _int_ ...
>
>True.
>
>> ... and the entire range of values is expressible
>> in a signed int.
>
>Not necessarily. An implementation is allowed to have UCHAR_MAX >
>INT_MAX, in which case unsigned char promotes to unsigned int rather
>than int. I'm aware of systems where UCHAR_MAX > LONG_MAX was true:
>char, short, int, and long were all 32 bits.

Yes, but in this context, that's obviously not the case as he
posted the behavior he saw.  I was merely explaining _why_ he
saw that behavior, vis the standard.

>> ...  These are called, "the usual arithmetic
>> conversions."
>
>Actually, what you're talking about are the integer promotions. The
>first step of the usual arithmetic conversions is to apply the integer
>promotions to each operand, but then a few other things happen as well.

This is correct, but IMHO too far down into the weeds.  Consider
section 6.3.1.1 para 3, which notes that, "the integer
promotions are applied only: ... 1. as part of the usual
arithmetic conversions".  Since we're talking about operands to
a binary operator, 6.3.1.8 applies.  6.3.1.8 is why converting
one side to unsigned is sufficient to get an unsigned result.

	- Dan C.