int*_t, int_least*_t, int_fast*_t signedness

Discussion in 'C Programming' started by Philipp Klaus Krause, Jun 14, 2010.

  1. I have seen these typically typedefed to a type that does not have the
    "signed" keyword, e.g. in my linux stdint.h (it's the same in e.g. sdcc):

    typedef int int_fast16_t;

    is this a correct way to create the int_fast16_t type? I would have
    expected it to be e.g.:

    typedef signed int int_fast16_t;

    and was quite surprised when I found my int_fast16_t bitfield to be
    unsigned.

    Philipp
    Philipp Klaus Krause, Jun 14, 2010
    #1
    1. Advertising

  2. Philipp Klaus Krause <> writes:

    > I have seen these typically typedefed to a type that does not have the
    > "signed" keyword, e.g. in my linux stdint.h (it's the same in e.g. sdcc):
    >
    > typedef int int_fast16_t;
    >
    > is this a correct way to create the int_fast16_t type?


    Looks fine to me.

    > I would have
    > expected it to be e.g.:
    >
    > typedef signed int int_fast16_t;


    That means the same: int is signed int. Unsigned types need the
    'unsigned' keyword but signed types do not need 'signed'. There are two
    exceptions: plain 'char' and bit-fields declared with plain 'int'. It
    is up to the implementation to decide if these are signed or unsigned.

    > and was quite surprised when I found my int_fast16_t bitfield to be
    > unsigned.


    You found one of the exceptions! You can decide on the signedness of a
    bit field by being explicit about it. BTW int must have at least 16
    bits so there is no point in using int_fast16_t rather than int. If a
    wider int is required to be "fast" on some machine, you will loose the
    benefit by making it a bitfield. I.e. just use 'signed int'.

    [This does exclude some possible peculiar corner cases on, say, sign and
    magnitude machines.]

    --
    Ben.
    Ben Bacarisse, Jun 14, 2010
    #2
    1. Advertising

  3. Philipp Klaus Krause

    Eric Sosman Guest

    On 6/14/2010 5:24 AM, Philipp Klaus Krause wrote:
    > I have seen these typically typedefed to a type that does not have the
    > "signed" keyword, e.g. in my linux stdint.h (it's the same in e.g. sdcc):
    >
    > typedef int int_fast16_t;
    >
    > is this a correct way to create the int_fast16_t type? I would have
    > expected it to be e.g.:
    >
    > typedef signed int int_fast16_t;
    >
    > and was quite surprised when I found my int_fast16_t bitfield to be
    > unsigned.


    Adding to Ben Bacarisse's response, note that the only
    universally portable bit-field "base types" are signed int,
    unsigned int, and (in C99) _Bool. Any other types are usable
    at the implementation's discretion; some may accept them and
    some may not. If an implementation accepts additional types,
    the semantics are the implementation's business.

    In short, the signedness of a bit-field with the base type
    int_fast16_t is not specified by the Standard, so your compiler
    has not broken the rules of C by making it unsigned.

    --
    Eric Sosman
    lid
    Eric Sosman, Jun 14, 2010
    #3
  4. Eric Sosman <> writes:
    [...]
    > Adding to Ben Bacarisse's response, note that the only
    > universally portable bit-field "base types" are signed int,
    > unsigned int, and (in C99) _Bool. Any other types are usable
    > at the implementation's discretion; some may accept them and
    > some may not. If an implementation accepts additional types,
    > the semantics are the implementation's business.


    int is also universally portable, but it's implementation-defined
    whether it's signed or unsigned. Because of this, it rarely makes
    sense to have a bit-field of type signed int.

    > In short, the signedness of a bit-field with the base type
    > int_fast16_t is not specified by the Standard, so your compiler
    > has not broken the rules of C by making it unsigned.


    To clarify, not only the signedness, but the legality, of
    an int_fast16_t bit field is not specified by the Standard.
    If int_fast16_t happens to be a typedef for int, then an int_fast16_t
    bit field is legal and of impementation-defined signedness. If not,
    an int_fast16_t bit field is legal only if the implementation
    supports it as an extension.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Jun 14, 2010
    #4
  5. Philipp Klaus Krause

    Eric Sosman Guest

    On 6/14/2010 11:16 AM, Keith Thompson wrote:
    > Eric Sosman<> writes:
    > [...]
    >> Adding to Ben Bacarisse's response, note that the only
    >> universally portable bit-field "base types" are signed int,
    >> unsigned int, and (in C99) _Bool. Any other types are usable
    >> at the implementation's discretion; some may accept them and
    >> some may not. If an implementation accepts additional types,
    >> the semantics are the implementation's business.

    >
    > int is also universally portable, but it's implementation-defined
    > whether it's signed or unsigned.


    That's why I left it out of the "universally portable" list,
    but perhaps I should have been clearer: Yes, plain int is accepted
    by all conforming implementations, but the semantics are not
    portable since they vary from implementation to implementation.

    > Because of this, it rarely makes
    > sense to have a bit-field of type signed int.


    Did you mean to say "plain int" here? If not, could you
    explain why it rarely makes sense to have a bit-field with an
    assuredly negative value?

    --
    Eric Sosman
    lid
    Eric Sosman, Jun 14, 2010
    #5
  6. Eric Sosman <> writes:
    > On 6/14/2010 11:16 AM, Keith Thompson wrote:

    [...]
    >> Because of this, it rarely makes
    >> sense to have a bit-field of type signed int.

    >
    > Did you mean to say "plain int" here? If not, could you
    > explain why it rarely makes sense to have a bit-field with an
    > assuredly negative value?


    Yes, I meant to say "plain int". Sorry.

    (Signed bit fields are rarer than unsigned bit fields, but they can
    certainly make sense.)

    As for using plain int, I can imagine cases where you want a bit field
    to occupy N bits, but you're only going to store values in the range
    0..2**(N-1)-1, so you don't care whether it's signed or unsigned.
    In that case, letting the implementation choose whichever is more
    efficient makes some sense.

    Or you might be willing to depend on the implementation-defined
    signedness of a plain int bit-field, but then you might as well use
    "signed int" or "unsigned int" explicitly.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Jun 14, 2010
    #6
    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. Peter
    Replies:
    5
    Views:
    13,998
    Dale King
    Jun 2, 2006
  2. Schnoffos
    Replies:
    2
    Views:
    1,199
    Martien Verbruggen
    Jun 27, 2003
  3. Hal Styli
    Replies:
    14
    Views:
    1,615
    Old Wolf
    Jan 20, 2004
  4. Frederick Gotham

    Bitshifting independant of signedness

    Frederick Gotham, Aug 24, 2006, in forum: C Programming
    Replies:
    4
    Views:
    328
    Michael Mair
    Aug 25, 2006
  5. Pietro Cerutti

    char * signedness

    Pietro Cerutti, Jul 5, 2007, in forum: C Programming
    Replies:
    17
    Views:
    615
Loading...

Share This Page