Deutsch   English   Français   Italiano  
<vhsnff$pk5$1@reader2.panix.com>

View for Bookmarking (what is this?)
Look up another Usenet article

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: Sat, 23 Nov 2024 14:05:35 -0000 (UTC)
Organization: PANIX Public Access Internet and UNIX, NYC
Message-ID: <vhsnff$pk5$1@reader2.panix.com>
References: <uu54la$3su5b$6@dont-email.me> <e47664d3-7f9b-4e67-aa73-b72c6cc0687a@alumni.caltech.edu> <vhr0uc$656$1@reader2.panix.com> <vhrmk1$1ivhr$1@dont-email.me>
Injection-Date: Sat, 23 Nov 2024 14:05:35 -0000 (UTC)
Injection-Info: reader2.panix.com; posting-host="spitfire.i.gajendra.net:166.84.136.80";
	logging-data="26245"; mail-complaints-to="abuse@panix.com"
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
Originator: cross@spitfire.i.gajendra.net (Dan Cross)
Bytes: 5450
Lines: 98

In article <vhrmk1$1ivhr$1@dont-email.me>,
James Kuyper  <jameskuyper@alumni.caltech.edu> wrote:
>On 11/22/24 17:34, Dan Cross wrote:
>> 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:
>...
>>>> ... 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.
>
>Your wording could easily give the false impression, to anyone who
>didn't already know better, that promotion of unsigned char to signed
>int is required by the standard, rather than it being dependent upon
>whether UCHAR_MAX > INT_MAX.

Actually I'm not sure that it did.  Note the part that you
quoted above that says, "the entire range values is expressible
in a signed int."  This implies UCHAR_MAX <= INT_MAX.  (By
"values" I meant, "values of that type", not specific values in
any given program).

Regardless, if you wanted to provide more detail, it would be
done more usefully by doing so within the context, "here's why
this is true in this context, but note that other contexts
exist in which this doesn't hold, and here's why..." etc.

>>>> ...  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".
>
>The latest draft of the standard that I have is n3096.pdf, dated
>2023-04-01.

As I mentioned, I'm looking at n3220.
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3220.pdf

You may want to looka t n3301, which seems to be the latest.
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3301.pdf

>In that draft, that wording is not present in paragraph 3,
>but only footnote 63, which is referenced by paragraph 2. That footnote
>does not contain the "1." that is present in your citation. That
>footnote goes on to list the other contexts in which integer promotions
>can occur: ", to certain argument expressions, to the operands of the
>unary +, -, and ~ operators, and to both operands of the shift
>operators, as specified by their respective subclauses."
>Which version are you quoting? I have copies of most of the draft
>standards that are available for free, but none of the final versions of
>the standards, since those cost money.

See above.

>> ...  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.
>
>Calling them the usual arithmetic conversions rather than the integer
>promotions is being unnecessarily vague. Your description only covers
>the integer promotions, it doesn't cover any of the other usual
>arithmetic conversions.

The integer promotions were the only relevant part in context.
Perhaps it would have allayed your concerns to say, "part of"?

>I'm going to try to come up with an analogy; the best one I could come
>up on the spur of the moment involves the US federal income tax form
>1040. It has a section called "Payments". The first four payments are
>all amounts that have been withheld from various income sources before
>you ever get a chance to spend the money. Most the other payments are
>things that you spent money on that you are entitled to take as a credit
>against your tax liability.
>What you've done is analogous to describing how withholding works, and
>even using the term "withheld", and then referring to what you've just
>described as "payments" rather than "amounts withheld", even though your
>description doesn't fit the tax credits, which are the other kinds of
>payments.

Sorry, I think this analogy is poor and unhelpful.  See the
above references.

	- Dan C.