Padding bits and char, unsigned char, signed char

Discussion in 'C Programming' started by Ioannis Vranos, Mar 28, 2008.

  1. Under C95:

    Is it guaranteed that char, unsigned char, signed char have no padding bits?
     
    Ioannis Vranos, Mar 28, 2008
    #1
    1. Advertising

  2. Ioannis Vranos

    CBFalconer Guest

    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
     
    CBFalconer, Mar 28, 2008
    #2
    1. Advertising

  3. 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?
     
    Harald van Dijk, Mar 28, 2008
    #3
  4. Ioannis Vranos

    pete Guest

    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
     
    pete, Mar 28, 2008
    #4
  5. Harald van Dijk <> 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.
     
    Ben Bacarisse, Mar 28, 2008
    #5
  6. Ben Bacarisse <> writes:
    > Harald van Dijk <> 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) <>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Mar 29, 2008
    #6
  7. Keith Thompson <> writes:

    > Ben Bacarisse <> writes:
    >> Harald van Dijk <> 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.
     
    Ben Bacarisse, Mar 29, 2008
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. sarmin kho
    Replies:
    2
    Views:
    847
    A. Lloyd Flanagan
    Jun 15, 2004
  2. Miki Tebeka
    Replies:
    1
    Views:
    455
    Marcin 'Qrczak' Kowalczyk
    Jun 14, 2004
  3. Steffen Fiksdal

    void*, char*, unsigned char*, signed char*

    Steffen Fiksdal, May 8, 2005, in forum: C Programming
    Replies:
    1
    Views:
    617
    Jack Klein
    May 9, 2005
  4. Ioannis Vranos
    Replies:
    11
    Views:
    782
    Ioannis Vranos
    Mar 28, 2008
  5. Ioannis Vranos

    Padding bits in signed char

    Ioannis Vranos, Apr 14, 2009, in forum: C++
    Replies:
    5
    Views:
    883
    James Kanze
    Apr 15, 2009
Loading...

Share This Page