Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #120993 > unrolled thread

Re: Command Languages Versus Programming Languages

Back to article view | Back to comp.lang.c++

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Command Languages Versus Programming Languages James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-11-23 09:43 -0500
    Re: Command Languages Versus Programming Languages Richard Damon <richard@damon-family.org> - 2024-11-23 10:39 -0500
      Re: Command Languages Versus Programming Languages Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-11-26 04:14 -0800
        Re: Command Languages Versus Programming Languages Richard Damon <richard@damon-family.org> - 2024-11-26 10:02 -0500

#120993 — Re: Command Languages Versus Programming Languages

On 11/23/24 09:05, Dan Cross wrote:
> In article <vhrmk1$1ivhr$1@dont-email.me>,
> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
...
>> 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).

You paired that assertion with "`unsigned char` has _rank_
lower than _int_", which is a fact guaranteed by the standard, which
could easily give the impression that the comment about the range of
values was either explicitly stated in the standard, or correctly
inferrable from the statement about the ranks.


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

Partially. However since you described the integer promotions, and the
description you provided didn't fit any other part of the usual
arithmetic conversions, and the part you described has it's own special
name, and the integer promotions can occur without the usual arithmetic
conversions, it still seems to me more appropriate to say that what you
described were the integer promotions.

[toc] | [next] | [standalone]

#120995

On 11/23/24 9:43 AM, James Kuyper wrote:
> On 11/23/24 09:05, Dan Cross wrote:
>> In article <vhrmk1$1ivhr$1@dont-email.me>,
>> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
> ...
>>> 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).
> 
> You paired that assertion with "`unsigned char` has _rank_
> lower than _int_", which is a fact guaranteed by the standard, which
> could easily give the impression that the comment about the range of
> values was either explicitly stated in the standard, or correctly
> inferrable from the statement about the ranks.

I don't think unsigned char is guarateed by the standard to be less than 
that of int.

On a machine with wide bytes (like some DSP processors) sizeof int could 
be 1, which results is some unexpected results,
like UCHAR_MAX > INT_MAX.

> 
> 
> ...
>>>> ... 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"?
> 
> Partially. However since you described the integer promotions, and the
> description you provided didn't fit any other part of the usual
> arithmetic conversions, and the part you described has it's own special
> name, and the integer promotions can occur without the usual arithmetic
> conversions, it still seems to me more appropriate to say that what you
> described were the integer promotions.
> 

[toc] | [prev] | [next] | [standalone]

#121024

Richard Damon <richard@damon-family.org> writes:

> On 11/23/24 9:43 AM, James Kuyper wrote:
>
>> On 11/23/24 09:05, Dan Cross wrote:
>>
>>> In article <vhrmk1$1ivhr$1@dont-email.me>,
>>> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>>
>> ...
>>
>>>> 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).
>>
>> You paired that assertion with "`unsigned char` has _rank_ lower
>> than _int_", which is a fact guaranteed by the standard, which
>> could easily give the impression that the comment about the range
>> of values was either explicitly stated in the standard, or
>> correctly inferrable from the statement about the ranks.
>
> I don't think unsigned char is guarateed by the standard to be
> less than that of int.

The integer conversion rank of unsigned char is guaranteed to be
less than the integer conversion rank of int (which incidentally is
the same as the integer conversion rank of unsigned int).

But the set of values of unsigned char is not guaranteed to be a
subset of the set of values of int.

> On a machine with wide bytes (like some DSP processors) sizeof int
> could be 1, which results is some unexpected results,
> like UCHAR_MAX > INT_MAX.

sizeof (int) == 1 is sufficient but not necessary.

As long as CHAR_BIT > 15, it is possible for UCHAR_MAX > INT_MAX
regardless of the value of sizeof (int).

It would be amusing to see an implementation where CHAR_BIT == 16,
and sizeof (int) == sizeof (long) == sizeof (long long) == 4, but
nevertheless UCHAR_MAX > INT_MAX.

[toc] | [prev] | [next] | [standalone]

#121027

On 11/26/24 7:14 AM, Tim Rentsch wrote:
> Richard Damon <richard@damon-family.org> writes:
> 
>> On 11/23/24 9:43 AM, James Kuyper wrote:
>>
>>> On 11/23/24 09:05, Dan Cross wrote:
>>>
>>>> In article <vhrmk1$1ivhr$1@dont-email.me>,
>>>> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>>>
>>> ...
>>>
>>>>> 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).
>>>
>>> You paired that assertion with "`unsigned char` has _rank_ lower
>>> than _int_", which is a fact guaranteed by the standard, which
>>> could easily give the impression that the comment about the range
>>> of values was either explicitly stated in the standard, or
>>> correctly inferrable from the statement about the ranks.
>>
>> I don't think unsigned char is guarateed by the standard to be
>> less than that of int.
> 
> The integer conversion rank of unsigned char is guaranteed to be
> less than the integer conversion rank of int (which incidentally is
> the same as the integer conversion rank of unsigned int).

Right, I forgot that "conversion rank" ignores signess, and doesn't 
actually provide the full ranking of conversions.

> 
> But the set of values of unsigned char is not guaranteed to be a
> subset of the set of values of int.
> 
>> On a machine with wide bytes (like some DSP processors) sizeof int
>> could be 1, which results is some unexpected results,
>> like UCHAR_MAX > INT_MAX.
> 
> sizeof (int) == 1 is sufficient but not necessary.
> 
> As long as CHAR_BIT > 15, it is possible for UCHAR_MAX > INT_MAX
> regardless of the value of sizeof (int).
> 
> It would be amusing to see an implementation where CHAR_BIT == 16,
> and sizeof (int) == sizeof (long) == sizeof (long long) == 4, but
> nevertheless UCHAR_MAX > INT_MAX.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c++

csiph-web