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


Groups > comp.std.c > #6126

Re: Problem with ranks

From James Kuyper <jameskuyper@alumni.caltech.edu>
Newsgroups comp.std.c
Subject Re: Problem with ranks
Date 2020-05-30 02:48 -0400
Organization A noiseless patient Spider
Message-ID <rasvjd$r7k$1@dont-email.me> (permalink)
References <ym86jKAqoCXFYStC@bongo-ra.co>

Show all headers | View raw


On 5/29/20 9:55 PM, Spiros Bousbouras wrote:
> Assume an implementation with 2 extended integer types as follows :

I suspect that you don't mean the following type names to be interpreted
literally, but it would have been better for you to choose identifiers
for those types which are reserved to the implementation, such as
__int24_t and __uint40_t.

> - INT1 is signed , has 23 value bits and no corresponding unsigned type.

"The standard and extended signed integer types are collectively called
signed integer types." (6.2.5p4).
"For each of the signed integer types, there is a corresponding (but
different) unsigned integer type ..." (6.2.5p6).

> - UINT1 is unsigned , has 40 value bits and no corresponding signed type.

That, however, is permitted, since 6.2.5p6 is asymmetrical.

> - Both have rank greater than  int .
> - The rank of UINT1 is smaller than the rank of INT1 .
> 
> The last stipulation is perverse but I don't see anything in "6.3.1.1
> Boolean, characters, and integers" which forbids it.

I believe you are correct about that, and I agree that it's a problem -
but not because of what you wrote below:

> With the above , if you have an addition where one operand is of type INT1
> and the other of type UINT1 then none of the possibilities (rules) in
> "6.3.1.8 Usual arithmetic conversions"  after the part  "Otherwise, the integer
> promotions are performed on both operands. Then the following rules are
> applied to the promoted operands:"  is applicable.

Since there is required to be a corresponding unsigned integer type, the
last rule would apply:

"Otherwise, both operands are converted to the unsigned integer type
corresponding to the type of the operand with signed integer type."

That rule specifies a conversion that would loose information from the
signed value, which is what I consider to be bad about the fact that
such an implementation is allowed.

Back to comp.std.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Problem with ranks Spiros Bousbouras <spibou@gmail.com> - 2020-05-30 01:55 +0000
  Re: Problem with ranks James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-05-30 02:48 -0400
    Re: Problem with ranks Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-05-30 02:18 -0700
      Re: Problem with ranks jameskuyper@alumni.caltech.edu - 2020-05-30 07:11 -0700
        Re: Problem with ranks Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-06-28 05:54 -0700
    Re: Problem with ranks James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-05-30 09:04 -0400
  Re: Problem with ranks Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-05-30 02:11 -0700

csiph-web