Re: Command Languages Versus Programming Languages

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.

...  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. 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.

...  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.

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.