Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Padding bits and char, unsigned char, signed char

Reply
Thread Tools

Padding bits and char, unsigned char, signed char

 
 
Ioannis Vranos
Guest
Posts: n/a
 
      03-28-2008
Under C95:

Is it guaranteed that char, unsigned char, signed char have no padding bits?
 
Reply With Quote
 
 
 
 
CBFalconer
Guest
Posts: n/a
 
      03-28-2008
Ioannis Vranos wrote:
>
> Under C95: Is it guaranteed that char, unsigned char, signed
> char have no padding bits?


unsigned char, yes. The others by implication. I haven't checked
the standard. Why don't you?

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.



--
Posted via a free Usenet account from http://www.teranews.com

 
Reply With Quote
 
 
 
 
Harald van Dijk
Guest
Posts: n/a
 
      03-28-2008
On Fri, 28 Mar 2008 16:01:54 -0500, CBFalconer wrote:
> Ioannis Vranos wrote:
>> Under C95: Is it guaranteed that char, unsigned char, signed char have
>> no padding bits?


Just a note: padding bits are a concept introduced in the standard in
C99; C90/C95 left much more unspecified about the representation of
integer types.

> unsigned char, yes.


Where is this guarantee made? In C99, 5.2.4.2.1 makes it as clear as it
can: "The value UCHAR_MAX shall equal 2^CHAR_BIT - 1." I don't have a
copy of an older standard. Does it make the same guarantee?

> The others by implication.


How so? What's preventing a signed integer type and its corresponding
unsigned type from having a different number of padding bits?
 
Reply With Quote
 
pete
Guest
Posts: n/a
 
      03-28-2008
Harald van =?UTF-8?b?RMSzaw==?= wrote:
>
> On Fri, 28 Mar 2008 16:01:54 -0500, CBFalconer wrote:
> > Ioannis Vranos wrote:
> >> Under C95: Is it guaranteed that char,
> >> unsigned char, signed char have no padding bits?

>
> Just a note: padding bits are a concept introduced in the standard in
> C99; C90/C95 left much more unspecified about the representation of
> integer types.
>
> > unsigned char, yes.

>
> Where is this guarantee made?
> In C99, 5.2.4.2.1 makes it as clear as it
> can: "The value UCHAR_MAX shall equal 2^CHAR_BIT - 1." I don't have a
> copy of an older standard. Does it make the same guarantee?


It doesn't.
There's really nothing about padding in the "basic types" in C90.

> > The others by implication.

>
> How so? What's preventing a signed integer type and its corresponding
> unsigned type from having a different number of padding bits?


I think he meant char and signed char, but even then I disagree.

As far as I know, signed char can have padding bits.

--
pete
 
Reply With Quote
 
Ben Bacarisse
Guest
Posts: n/a
 
      03-28-2008
Harald van Dijk <(E-Mail Removed)> writes:

> On Fri, 28 Mar 2008 16:01:54 -0500, CBFalconer wrote:
>> Ioannis Vranos wrote:
>>> Under C95: Is it guaranteed that char, unsigned char, signed char have
>>> no padding bits?

>
> Just a note: padding bits are a concept introduced in the standard in
> C99; C90/C95 left much more unspecified about the representation of
> integer types.
>
>> unsigned char, yes.

>
> Where is this guarantee made? In C99, 5.2.4.2.1 makes it as clear as it
> can: "The value UCHAR_MAX shall equal 2^CHAR_BIT - 1."


But that alone is not enough, is it? The clearest statement comes
later in 6.2.6. p1: "For unsigned integer types other than unsigned
char, the bits of the object representation shall be divided into two
groups: value bits and padding bits (there need not be any of the
latter).". So, unsigned char has only value bits.

--
Ben.
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      03-29-2008
Ben Bacarisse <(E-Mail Removed)> writes:
> Harald van Dijk <(E-Mail Removed)> writes:
>> On Fri, 28 Mar 2008 16:01:54 -0500, CBFalconer wrote:
>>> Ioannis Vranos wrote:
>>>> Under C95: Is it guaranteed that char, unsigned char, signed char have
>>>> no padding bits?

>>
>> Just a note: padding bits are a concept introduced in the standard in
>> C99; C90/C95 left much more unspecified about the representation of
>> integer types.
>>
>>> unsigned char, yes.

>>
>> Where is this guarantee made? In C99, 5.2.4.2.1 makes it as clear as it
>> can: "The value UCHAR_MAX shall equal 2^CHAR_BIT - 1."

>
> But that alone is not enough, is it?


I believe it is. Assume, for example, CHAR_BIT==8. Then there are
256 possible values for the 8 bits making up an unsigned char.
UCHAR_MAX must equal 255, so there are 256 distinct values, each of
which must be distinctly representable by one of those bit patterns.
There are no bit patterns left over, so there can't be any padding
bits or trap representations. This generalizes to other values of
CHAR_BIT.

> The clearest statement comes
> later in 6.2.6. p1: "For unsigned integer types other than unsigned
> char, the bits of the object representation shall be divided into two
> groups: value bits and padding bits (there need not be any of the
> latter).". So, unsigned char has only value bits.


You mean 6.2.6.2p1.

This describes types other than unsigned char; it says nothing about
unsigned char itself. If unsigned char were composed entirely of
naughty bits, with no value bits or padding bits at all, it would not
contradict that sentence (though it would contradict other
requirements).

In fact, the phrase "other than unsigned char" could have been left
out. The bits of the object representation of *any* unsigned type are
divided into value bits and padding bits, and there needn't be any
padding bits. Furthermore, for unsigned char there *must* not be any
padding bits (as implied by 5.2.4.2.1).

--
Keith Thompson (The_Other_Keith) <(E-Mail Removed)>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Ben Bacarisse
Guest
Posts: n/a
 
      03-29-2008
Keith Thompson <(E-Mail Removed)> writes:

> Ben Bacarisse <(E-Mail Removed)> writes:
>> Harald van Dijk <(E-Mail Removed)> writes:
>>> On Fri, 28 Mar 2008 16:01:54 -0500, CBFalconer wrote:
>>>> Ioannis Vranos wrote:
>>>>> Under C95: Is it guaranteed that char, unsigned char, signed char have
>>>>> no padding bits?
>>>
>>> Just a note: padding bits are a concept introduced in the standard in
>>> C99; C90/C95 left much more unspecified about the representation of
>>> integer types.
>>>
>>>> unsigned char, yes.
>>>
>>> Where is this guarantee made? In C99, 5.2.4.2.1 makes it as clear as it
>>> can: "The value UCHAR_MAX shall equal 2^CHAR_BIT - 1."

>>
>> But that alone is not enough, is it?

>
> I believe it is. Assume, for example, CHAR_BIT==8. Then there are
> 256 possible values for the 8 bits making up an unsigned char.
> UCHAR_MAX must equal 255, so there are 256 distinct values, each of
> which must be distinctly representable by one of those bit patterns.
> There are no bit patterns left over, so there can't be any padding
> bits or trap representations. This generalizes to other values of
> CHAR_BIT.


Yes, I got the arithmetic bit! My problem with the statement is that
is tells one that CHAR_BIT must be equal to the number of value bits,
not that there are no other bits.

I think I was just imagining trouble. I wanted some other text to say
that CHAR_BIT counts all the bits, but I think its definition does
that: "the number of bits for smallest object that is not a bit-field
(byte)". This must include any padding, so that is indeed enough. In
all these years, I'd never read the definition of CHAR_BIT.

>> The clearest statement comes
>> later in 6.2.6. p1: "For unsigned integer types other than unsigned
>> char, the bits of the object representation shall be divided into two
>> groups: value bits and padding bits (there need not be any of the
>> latter).". So, unsigned char has only value bits.

>
> You mean 6.2.6.2p1.


Yes. Thanks.

> This describes types other than unsigned char; it says nothing about
> unsigned char itself. If unsigned char were composed entirely of
> naughty bits, with no value bits or padding bits at all, it would not
> contradict that sentence (though it would contradict other
> requirements).
>
> In fact, the phrase "other than unsigned char" could have been left
> out. The bits of the object representation of *any* unsigned type are
> divided into value bits and padding bits, and there needn't be any
> padding bits. Furthermore, for unsigned char there *must* not be any
> padding bits (as implied by 5.2.4.2.1).


Right. I can see that now. In fact, if the phrase were left out,
my misreading of it would have been impossible.

--
Ben.
 
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
Padding bits in signed char Ioannis Vranos C++ 5 04-15-2009 07:50 AM
Padding bits and char, unsigned char, signed char Ioannis Vranos C++ 11 03-28-2008 10:47 PM
void*, char*, unsigned char*, signed char* Steffen Fiksdal C Programming 1 05-09-2005 02:33 AM
what about unsigned and signed 8 bits number, 16 bits, etc?? sarmin kho Python 2 06-15-2004 06:40 PM
Re: what about unsigned and signed 8 bits number, 16 bits, etc?? Miki Tebeka Python 1 06-14-2004 03:19 PM



Advertisments