Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > C99 stdint.h

Reply
Thread Tools

C99 stdint.h

 
 
Frederick Gotham
Guest
Posts: n/a
 
      08-05-2006
Here's an excerpt from the Dinkumware library reference:
__________
| uint8_t, uint16_t, uint32_t, uint64_t
|
| The types each specify an unsigned integer type
| whose representation has exactly eight, 16, 32,
| or 64 bits, respectively.
__________

How could that be possible if we had a 36-Bit system such as the following?

char: 9-Bit
short: 18-Bit
int: 36-Bit
long: 36-Bit

--

Frederick Gotham
 
Reply With Quote
 
 
 
 
Richard Heathfield
Guest
Posts: n/a
 
      08-05-2006
Frederick Gotham said:

> Here's an excerpt from the Dinkumware library reference:
> __________
> | uint8_t, uint16_t, uint32_t, uint64_t
> |
> | The types each specify an unsigned integer type
> | whose representation has exactly eight, 16, 32,
> | or 64 bits, respectively.
> __________
>
> How could that be possible if we had a 36-Bit system such as the
> following?
>
> char: 9-Bit
> short: 18-Bit
> int: 36-Bit
> long: 36-Bit


Well, it couldn't, obviously. And even if it could, would it matter?

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
 
Reply With Quote
 
 
 
 
Frederick Gotham
Guest
Posts: n/a
 
      08-05-2006
Richard Heathfield posted:

> Frederick Gotham said:
>
>> Here's an excerpt from the Dinkumware library reference:
>> __________
>> | uint8_t, uint16_t, uint32_t, uint64_t
>> |
>> | The types each specify an unsigned integer type
>> | whose representation has exactly eight, 16, 32,
>> | or 64 bits, respectively.
>> __________
>>
>> How could that be possible if we had a 36-Bit system such as the
>> following?
>>
>> char: 9-Bit
>> short: 18-Bit
>> int: 36-Bit
>> long: 36-Bit

>
> Well, it couldn't, obviously. And even if it could, would it matter?



I would understand if it read:

Where possible, the types "uint8_t, uint16_t, uint32_t, uint64_t"
denote an unsigned integer type whose representation has exactly...

But it doesn't say "where possible" -- it plainly states that these types
are available... ?

--

Frederick Gotham
 
Reply With Quote
 
Ulrich Eckhardt
Guest
Posts: n/a
 
      08-05-2006
Frederick Gotham wrote:
> | uint8_t, uint16_t, uint32_t, uint64_t

[...]
> How could that be possible if we had a 36-Bit system such as the
> following?
>
> char: 9-Bit
> short: 18-Bit
> int: 36-Bit
> long: 36-Bit


IIRC, the terms state that those typedefs are present _if_ there are
suitable types on the system. In the case of a 9 bit byte, they just
wouldn't be there.

What you would get would be int_least8_t etc though, I think.

Uli

 
Reply With Quote
 
Schraalhans Keukenmeester
Guest
Posts: n/a
 
      08-05-2006
Frederick Gotham wrote:
> Here's an excerpt from the Dinkumware library reference:
> __________
> | uint8_t, uint16_t, uint32_t, uint64_t
> |
> | The types each specify an unsigned integer type
> | whose representation has exactly eight, 16, 32,
> | or 64 bits, respectively.
> __________
>
> How could that be possible if we had a 36-Bit system such as the following?
>
> char: 9-Bit
> short: 18-Bit
> int: 36-Bit
> long: 36-Bit
>

I suppose in order to warrant C99 standard compliance the compiler for
such a system would have to cater for the necessary translation and
storage methods. How it does that may not be the programmer's concern,
as long as he/she sticks to standard C.

A similar 'problem' exists for 64 bit variables on 32-bit machines. To
the programmer the long longs are available as if they were a system
default, yet the compiler translates all relevant code to multiple
32-bit manipulations.

Is there a particular (practical) reason for this question??
Sh.
 
Reply With Quote
 
Tim Prince
Guest
Posts: n/a
 
      08-05-2006
Frederick Gotham wrote:
> Richard Heathfield posted:
>
>> Frederick Gotham said:
>>
>>> Here's an excerpt from the Dinkumware library reference:
>>> __________
>>> | uint8_t, uint16_t, uint32_t, uint64_t
>>> |
>>> | The types each specify an unsigned integer type
>>> | whose representation has exactly eight, 16, 32,
>>> | or 64 bits, respectively.
>>> __________
>>>
>>> How could that be possible if we had a 36-Bit system such as the
>>> following?
>>>
>>> char: 9-Bit
>>> short: 18-Bit
>>> int: 36-Bit
>>> long: 36-Bit

>> Well, it couldn't, obviously. And even if it could, would it matter?

>
>
> I would understand if it read:
>
> Where possible, the types "uint8_t, uint16_t, uint32_t, uint64_t"
> denote an unsigned integer type whose representation has exactly...
>
> But it doesn't say "where possible" -- it plainly states that these types
> are available... ?
>

Perhaps Dinkumware don't support any 36-bit machines.
 
Reply With Quote
 
P.J. Plauger
Guest
Posts: n/a
 
      08-05-2006
"Tim Prince" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...

> Frederick Gotham wrote:
>> Richard Heathfield posted:
>>
>>> Frederick Gotham said:
>>>
>>>> Here's an excerpt from the Dinkumware library reference:
>>>> __________
>>>> | uint8_t, uint16_t, uint32_t, uint64_t
>>>> |
>>>> | The types each specify an unsigned integer type
>>>> | whose representation has exactly eight, 16, 32,
>>>> | or 64 bits, respectively.
>>>> __________
>>>>
>>>> How could that be possible if we had a 36-Bit system such as the
>>>> following?
>>>>
>>>> char: 9-Bit
>>>> short: 18-Bit
>>>> int: 36-Bit
>>>> long: 36-Bit
>>> Well, it couldn't, obviously. And even if it could, would it matter?

>>
>>
>> I would understand if it read:
>>
>> Where possible, the types "uint8_t, uint16_t, uint32_t, uint64_t"
>> denote an unsigned integer type whose representation has exactly...
>>
>> But it doesn't say "where possible" -- it plainly states that these types
>> are available... ?
>>

> Perhaps Dinkumware don't support any 36-bit machines.


We don't in our prepackaged libraries, to be sure. Our OEM customers
are free to modify our headers, and documentation, to meet more
specific needs.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com


 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      08-05-2006
Frederick Gotham <(E-Mail Removed)> writes:
> Here's an excerpt from the Dinkumware library reference:
> __________
> | uint8_t, uint16_t, uint32_t, uint64_t
> |
> | The types each specify an unsigned integer type
> | whose representation has exactly eight, 16, 32,
> | or 64 bits, respectively.
> __________
>
> How could that be possible if we had a 36-Bit system such as the following?
>
> char: 9-Bit
> short: 18-Bit
> int: 36-Bit
> long: 36-Bit


It isn't. The uintN_t types are optional.

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
 
Reply With Quote
 
Jack Klein
Guest
Posts: n/a
 
      08-06-2006
On Sat, 05 Aug 2006 21:45:52 GMT, Keith Thompson <(E-Mail Removed)> wrote
in comp.lang.c:

> Frederick Gotham <(E-Mail Removed)> writes:
> > Here's an excerpt from the Dinkumware library reference:
> > __________
> > | uint8_t, uint16_t, uint32_t, uint64_t
> > |
> > | The types each specify an unsigned integer type
> > | whose representation has exactly eight, 16, 32,
> > | or 64 bits, respectively.
> > __________
> >
> > How could that be possible if we had a 36-Bit system such as the following?
> >
> > char: 9-Bit
> > short: 18-Bit
> > int: 36-Bit
> > long: 36-Bit

>
> It isn't. The uintN_t types are optional.


Actually, "semi optional" would be more accurate. If an
implementation provides any or all types which meet the definition,
namely exactly that many bits, no padding, and 2's complement
representation for negative values in the signed types, it is required
to provide the appropriate typedefs.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html
 
Reply With Quote
 
Jack Klein
Guest
Posts: n/a
 
      08-06-2006
On Sat, 05 Aug 2006 13:56:08 GMT, Frederick Gotham
<(E-Mail Removed)> wrote in comp.lang.c:

> Here's an excerpt from the Dinkumware library reference:
> __________
> | uint8_t, uint16_t, uint32_t, uint64_t
> |
> | The types each specify an unsigned integer type
> | whose representation has exactly eight, 16, 32,
> | or 64 bits, respectively.
> __________
>
> How could that be possible if we had a 36-Bit system such as the following?
>
> char: 9-Bit
> short: 18-Bit
> int: 36-Bit
> long: 36-Bit


Purchase and read a copy of the C standard, 1999 or later, and all
will be revealed to you.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html
 
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
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
ISO C89 and ISO C99 jrefactors@hotmail.com C++ 13 12-20-2004 06:29 AM
How to check whether my GCC compiler support C99 standard or not? Peng Yu C++ 2 09-29-2004 04:09 PM
C99 Complex number support in C++ kartik C++ 3 07-31-2004 09:11 PM



Advertisments