Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > C99 integer types

Reply
Thread Tools

C99 integer types

 
 
Eric Sosman
Guest
Posts: n/a
 
      07-31-2012
On 7/30/2012 8:15 PM, Ronald Landheer-Cieslak wrote:
>[...]
> I didn't want to imply that I had any problem with the added complexity
> (and don't think I had): I understand very well that there's a real need to
> specify in detail how these sorts of conversions need to work.
>
> However, I think it only works as expected if the signed integer type is a
> two's complement type. 6.2.6.2s2 allows for three representations, two of
> which won't work as expected when ULONG_MAX + 1 is "repeatedly added" as in
> 6.3.1.3p2.


In what way are your expectations taken aback? I expect (for
example) that negative one will convert to ULONG_MAX, no matter
how the negative one is represented, that negative two will give
ULONG_MAX-1, that zero will give zero, seven seven, and so on.

> I've never worked with hardware that had anything other than two's
> complement integers, but that is what I meant with the
> "implementation-defined" bit.


I worked (very briefly and not in C) with a ones'-complement
Univac machine, back in the 1970's. Before that, I worked with a
signed-magnitude machine -- but it worked in decimal, not binary,
and definitely had no C implementation!

In recent years ("recent" meaning "since sometime in the Ford
administration") I've seen only two's-complement platforms. They're
the wave of the present.

--
Eric Sosman
http://www.velocityreviews.com/forums/(E-Mail Removed)d
 
Reply With Quote
 
 
 
 
Ronald Landheer-Cieslak
Guest
Posts: n/a
 
      07-31-2012
Eric Sosman <(E-Mail Removed)> wrote:
> On 7/30/2012 8:15 PM, Ronald Landheer-Cieslak wrote:
>> [...]
>> I didn't want to imply that I had any problem with the added complexity
>> (and don't think I had): I understand very well that there's a real need to
>> specify in detail how these sorts of conversions need to work.
>>
>> However, I think it only works as expected if the signed integer type is a
>> two's complement type. 6.2.6.2s2 allows for three representations, two of
>> which won't work as expected when ULONG_MAX + 1 is "repeatedly added" as in
>> 6.3.1.3p2.

>
> In what way are your expectations taken aback? I expect (for
> example) that negative one will convert to ULONG_MAX, no matter
> how the negative one is represented, that negative two will give
> ULONG_MAX-1, that zero will give zero, seven seven, and so on.

Hmmm. On first reading I though negative 0 in one's complement would yield
1 after conversion, but while writing the example out I found my bug (it
would yield zero)...

Same thing for sign and magnitude...

It's the footnote (49) that really clarifies it: "The rules describe the
arithmetic on the mathematical value...".

So, my bad

rlc



--
Software analyst & developer -- http://rlc.vlinder.ca
 
Reply With Quote
 
 
 
 
James Kuyper
Guest
Posts: n/a
 
      07-31-2012
On 07/30/2012 08:15 PM, Ronald Landheer-Cieslak wrote:
> James Kuyper <(E-Mail Removed)> wrote:
>> On 07/30/2012 02:26 PM, Ronald Landheer-Cieslak wrote:

....
>> (and
>>> comparing a negative signed short to an unsigned long still yields
>>> implementation-defined results).

>>
>> In such a comparison, the negative signed short value is first promoted
>> to an 'int', without change in value. Then that value is converted to
>> unsigned long. That conversion is well-defined: it is performed by
>> adding ULONG_MAX+1 to the negative value, with a result that is
>> necessarily representable as unsigned long. That result is then compared
>> with the other unsigned long value.
>>
>> Since the value of ULONG_MAX is implementation-defined, the result could
>> be described as implementation-defined, but once the value for ULONG_MAX
>> has been defined by the implementation, the standard gives the
>> implementation no additional freedom when performing that comparison.
>>
>> Does that correspond with what you meant?

> Yes. That and the fact that due to the addition in 6.3.1.3p2 the result
> differs on systems depending how signed integers are implemented (i.e. it
> works as expected only for two's complement signed integers).


given:

int s_ul_comp(short i, unsigned long ul)
{
return i < ul;
}

If i < 0 that function will return a value of 1 if and only if the
mathematical value of ULONG_MAX + 1 + i is less than the value of ul.
That value depends only upon the values of i, ul, and ULONG_MAX. It does
not depend in any way upon whether 2's complement is used to represent
the signed values involved in that calculation.
--
James Kuyper
 
Reply With Quote
 
Tim Rentsch
Guest
Posts: n/a
 
      09-07-2012
James Kuyper <(E-Mail Removed)> writes:

> On 07/30/2012 02:26 PM, Ronald Landheer-Cieslak wrote:
>> Eric Sosman <(E-Mail Removed)> wrote:

> ...
>>> Eventually, when C needs to perform "integer promotions" or
>>> "usual arithmetic conversions," its choice of target type for
>>> integers is driven by the integer conversion rank(s) of the original
>>> type(s) involved.

>>
>> OK, so it basically formalizes the conversions that the integer types goes
>> through to end up with either something useful or something
>> implementation-defined, or both.
>>
>> Reading the draft Barry pointed to, it doesn't seem to actually change any
>> of the rules as they were before - just formalize them, is that right?

>
> I believe that integer conversion rank was put into the very first
> version of the C standard, nearly a quarter century ago. [snip]


A reasonable guess, but it wasn't.
 
Reply With Quote
 
Tim Rentsch
Guest
Posts: n/a
 
      09-07-2012
Eric Sosman <(E-Mail Removed)> writes:

> On 7/28/2012 9:12 PM, justinx wrote:
>> [... reformatted for legibility ...]
>> In <stdint.h> the follow types are defined:
>>
>> typedef unsigned int uint_fast32_t;
>> typedef uint32_t uint_least32_t;
>> typedef unsigned long uint32_t;

> [..snip..]
>
>> Any insight in to the selection process for establishing the
>> underlying data types for the fixed, minimum and fastest width
>> types would be great.

>
> If by "fixed" you mean "exact-width" (7.20.1.1), the selection
> is straightforward: The implementation declares a type of exactly
> the specified width (if it has one) that uses two's complement (for
> signed exact-width types). If there's more than one such type,
> the implementation can use any of them. The choices for uintN_t
> and intN_t are independent: One might be `unsigned long' while the
> other is `__builtin_twos_complement_32'. [snip]


Actually the choices for corresponding types in <stdint.h> are
not independent. If either is supplied then both must be, and
the unsigned type must be the unsigned type corresponding to the
signed type, and vice versa.

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
warning: use of C99 long long integer constant Sebastian Faust C Programming 23 04-02-2008 12:09 PM
Number of bits in C99 float types? Dom Fulton C Programming 27 03-19-2008 06:34 AM
Standard integer types vs <stdint.h> types euler70@gmail.com C Programming 163 01-28-2008 03:21 PM
Difference between "library parts" of C99 and "language parts" of C99 albert.neu@gmail.com C Programming 3 03-31-2007 08:14 PM
C99 struct initialization (C99/gcc) jilerner@yahoo.com C Programming 3 02-20-2006 04:41 AM



Advertisments