Typedef Bug/Error

Discussion in 'C Programming' started by Pranav, Sep 1, 2008.

  1. Pranav

    Pranav Guest

    #include<stdio.h>
    int main()
    {
    typedef int R1;
    typedef int R2;
    typedef long int R3;

    unsigned R1 n1;
    long R2 n2;
    R3 n3;

    n1=123456789;
    n2=123456789;
    n3=123456789;
    printf("%u..%d\n",n1,sizeof(n1));
    printf("%ld..%d\n",n2,sizeof(n2));
    printf("%ld..%d\n",n3,sizeof(n3));
    return 0;
    }

    Getting Following Errors..,
    Teast2.c syntax error before "n1"
    Teast2.c syntax error before "n2"
    Teast2.c `n1' undeclared (first use in this function)
    Teast2.c `n2' undeclared (first use in this function)
     
    Pranav, Sep 1, 2008
    #1
    1. Advertising

  2. On Mon, 01 Sep 2008 10:43:54 -0700, Pranav wrote:
    > typedef int R1;
    > unsigned R1 n1;


    typedefs are not macros. You defined R1 as a typedef for (signed) int. You
    cannot make it unsigned later.
     
    Harald van Dijk, Sep 1, 2008
    #2
    1. Advertising

  3. Pranav

    Pranav Guest

    On Sep 1, 10:51 pm, Harald van D©¦k <> wrote:
    > On Mon, 01 Sep 2008 10:43:54 -0700, Pranav wrote:
    > > typedef int R1;
    > > unsigned R1 n1;

    >
    > typedefs are not macros. You defined R1 as a typedef for (signed) int. You
    > cannot make it unsigned later.


    K..., Here Lies The Problem.., Thank You Harald van D©¦k..,
     
    Pranav, Sep 1, 2008
    #3
  4. Harald van D©¦k <> wrote:
    > Pranav wrote:
    > > typedef int R1;
    > > unsigned R1 n1;

    >
    > typedefs are not macros. You defined R1 as a typedef
    > for (signed) int. You cannot make it unsigned later.


    Hence why <stdint.h> typedefs uintN_t as well as intN_t.
    Note that a C99 implementation with CHAR_BIT == 32 must
    provide uint32_t, but it need not provide int32_t.

    --
    Peter
     
    Peter Nilsson, Sep 2, 2008
    #4
  5. On Mon, 01 Sep 2008 18:01:04 -0700, Peter Nilsson wrote:
    > Note that a C99 implementation with CHAR_BIT == 32 must
    > provide uint32_t, but it need not provide int32_t.


    It must provide both.

    7.18.1 Integer types
    1 When typedef names differing only in the absence or presence of the
    initial u are defined, they shall denote corresponding signed and
    unsigned types as described in 6.2.5; an implementation providing one
    of these corresponding types shall also provide the other.
     
    Harald van Dijk, Sep 2, 2008
    #5
  6. On Sep 1, 9:01 pm, Peter Nilsson <> wrote:
    > Harald van D©¦k <> wrote:
    >
    > > Pranav wrote:
    > > > typedef int R1;
    > > > unsigned R1 n1;

    >
    > > typedefs are not macros. You defined R1 as a typedef
    > > for (signed) int. You cannot make it unsigned later.

    >
    > Hence why <stdint.h> typedefs uintN_t as well as intN_t.
    > Note that a C99 implementation with CHAR_BIT == 32 must
    > provide uint32_t, but it need not provide int32_t.



    If the implementation provides 32-bit integers without padding bits
    and uses two's complement representation, both uint32_t and int32_t
    must be provided, otherwise neither shall be provided; in no case can
    one be provided without the other (7.18.1p1).

    --
    Robert Gamble
     
    Robert Gamble, Sep 2, 2008
    #6
  7. Harald van D©¦k <> wrote:
    > Peter Nilsson wrote:
    > > Note that a C99 implementation with CHAR_BIT == 32 must
    > > provide uint32_t, but it need not provide int32_t.

    >
    > It must provide both.
    >
    > 7.18.1 Integer types
    > 1 When typedef names differing only in the absence or
    > presence of the initial u are defined, they shall denote
    > corresponding signed and unsigned types as described in
    > 6.2.5; an implementation providing one of these
    > corresponding types shall also provide the other.


    It says that if that _both_ uint32_t and int32_t exist,
    they must be corresponding types. It does not say the
    presence of uint32_t requires the corresponding signed
    integer to be two's complement and without padding.

    --
    Peter
     
    Peter Nilsson, Sep 2, 2008
    #7
  8. Pranav

    Guest

    On Sep 3, 1:24 am, Peter Nilsson <> wrote:
    > Harald van D©¦k <> wrote:
    >
    > > Peter Nilsson wrote:
    > > > Note that a C99 implementation with CHAR_BIT == 32 must
    > > > provide uint32_t, but it need not provide int32_t.

    >
    > > It must provide both.

    >
    > > 7.18.1 Integer types
    > > 1 When typedef names differing only in the absence or
    > > presence of the initial u are defined, they shall denote
    > > corresponding signed and unsigned types as described in
    > > 6.2.5; an implementation providing one of these
    > > corresponding types shall also provide the other.

    >
    > It says that if that _both_ uint32_t and int32_t exist,
    > they must be corresponding types. It does not say the
    > presence of uint32_t requires the corresponding signed
    > integer to be two's complement and without padding.


    intN_t is *required* to be two's complement and without padding bits.
    See 7.18.1.1 p 1
     
    , Sep 2, 2008
    #8
  9. Robert Gamble <> wrote:
    > Peter Nilsson <> wrote:
    > > Harald van D©¦k <> wrote:
    > > > Pranav wrote:
    > > > > typedef int R1;
    > > > > unsigned R1 n1;
    > > >
    > > > typedefs are not macros. You defined R1 as a typedef
    > > > for (signed) int. You cannot make it unsigned later.

    > >
    > > Hence why <stdint.h> typedefs uintN_t as well as intN_t.
    > > Note that a C99 implementation with CHAR_BIT == 32 must
    > > provide uint32_t, but it need not provide int32_t.

    >
    > If the implementation provides 32-bit integers without
    > padding bits and uses two's complement representation,


    Let's say it does. Let's suppose int32_t is signed int.

    > both uint32_t and int32_t must be provided,


    I see nothing preventing the corresponding unsigned
    int from having the range 0..INT_MAX.

    > otherwise neither shall be provided; in no case can
    > one be provided without the other (7.18.1p1).


    If both exist, they must be corresponding types. That
    does not imply that if one meets the relevant criteria
    of an exact width integer type, so must the other.

    --
    Peter
     
    Peter Nilsson, Sep 2, 2008
    #9
  10. On Tue, 02 Sep 2008 15:24:22 -0700, Peter Nilsson wrote:
    > Harald van Dijk <> wrote:
    >> Peter Nilsson wrote:
    >> > Note that a C99 implementation with CHAR_BIT == 32 must provide
    >> > uint32_t, but it need not provide int32_t.

    >>
    >> It must provide both.
    >>
    >> 7.18.1 Integer types
    >> 1 When typedef names differing only in the absence or presence of the
    >> initial u are defined, they shall denote corresponding signed and
    >> unsigned types as described in 6.2.5; an implementation providing one
    >> of these corresponding types shall also provide the other.

    >
    > It says that if that _both_ uint32_t and int32_t exist, they must be
    > corresponding types. It does not say the presence of uint32_t requires
    > the corresponding signed integer to be two's complement and without
    > padding.


    I'm not seeing how you interpret the text. Could you give a concrete
    example of an implementation you believe would be disallowed by "an
    implementation providing one of these corresponding types shall also
    provide the other"?
     
    Harald van Dijk, Sep 2, 2008
    #10
  11. Harald van D©¦k <> wrote:
    > Peter Nilsson wrote:
    > > Harald van D©¦k <> wrote:
    > > > Peter Nilsson wrote:
    > > > > Note that a C99 implementation with CHAR_BIT == 32
    > > > > must provide uint32_t, but it need not provide
    > > > > int32_t.
    > > >
    > > > It must provide both.
    > > >
    > > > 7.18.1 Integer types
    > > > 1 When typedef names differing only in the absence or
    > > > presence of the initial u are defined, they shall denote
    > > > corresponding signed and unsigned types as described in
    > > > 6.2.5; an implementation providing one of these
    > > > corresponding types shall also provide the other.

    > >
    > > It says that if that _both_ uint32_t and int32_t exist,
    > > they must be corresponding types. It does not say the
    > > presence of uint32_t requires the corresponding signed
    > > integer to be two's complement and without padding.

    >
    > I'm not seeing how you interpret the text. Could you give
    > a concrete example of an implementation you believe would
    > be disallowed by "an implementation providing one of these
    > corresponding types shall also provide the other"?


    How about I provide you with allowed implementations that
    don't meet your claim... :)

    Example 1:

    CHAR_BIT == 8
    sizeof(int) == 4
    UINT_MAX == 4294967295
    INT_MAX == 2147483647
    INT_MIN == -2147483647 /* sm or 1c, not 2c */

    Here, uint32_t exists as unsigned int and has a corresponding
    type under 6.2.5, namely signed int. However, signed int does
    not meet the criteria needed to be int32_t.

    Example 2:

    CHAR_BIT == 8
    sizeof(int) == 4
    INT_MAX == 2147483647
    INT_MIN == -2147483647-1
    UINT_MAX == 2147483647

    Here, int32_t exists and is signed int and has a corresponding
    type under 6.2.5, namely unsigned int. However unsigned int
    does not meet the criteria needed to be uint32_t.

    What 7.18.1 says is this that if int32_t is chosen as say
    signed int, and both unsigned int and unsigned long meet all
    other criteria for being uint32_t, then uint32_t must be
    unsigned int. It cannot be not unsigned long because that
    is not the corresponding type to int32_t/signed int under
    6.2.5.

    --
    Peter
     
    Peter Nilsson, Sep 3, 2008
    #11
  12. On Tue, 02 Sep 2008 16:31:29 -0700, Peter Nilsson wrote:
    > Harald van Dijk <> wrote:
    >> Peter Nilsson wrote:
    >> > Harald van Dijk <> wrote:
    >> > > Peter Nilsson wrote:
    >> > > > Note that a C99 implementation with CHAR_BIT == 32 must provide
    >> > > > uint32_t, but it need not provide int32_t.
    >> > >
    >> > > It must provide both.
    >> > >
    >> > > 7.18.1 Integer types
    >> > > 1 When typedef names differing only in the absence or presence of
    >> > > the initial u are defined, they shall denote corresponding signed
    >> > > and unsigned types as described in 6.2.5; an implementation
    >> > > providing one of these corresponding types shall also provide the
    >> > > other.
    >> >
    >> > It says that if that _both_ uint32_t and int32_t exist, they must be
    >> > corresponding types. It does not say the presence of uint32_t
    >> > requires the corresponding signed integer to be two's complement and
    >> > without padding.

    >>
    >> I'm not seeing how you interpret the text. Could you give a concrete
    >> example of an implementation you believe would be disallowed by "an
    >> implementation providing one of these corresponding types shall also
    >> provide the other"?

    >
    > How about I provide you with allowed implementations that don't meet
    > your claim... :)


    That does not help me understand your position. If they don't meet my
    claim, which comes from the standard, they are not conforming
    implementations, unless my claim is an incorrect interpretation. I am
    trying to understand why you think it _is_ incorrect. Your examples show
    why it _should be_ incorrect.
     
    Harald van Dijk, Sep 3, 2008
    #12
  13. wrote:
    > Peter Nilsson <> wrote:
    > > Harald van D©¦k <> wrote:
    > > > 7.18.1 Integer types
    > > > 1 When typedef names differing only in the absence
    > > > or presence of the initial u are defined, they shall
    > > > denote corresponding signed and unsigned types as
    > > > described in 6.2.5; an implementation providing one
    > > > of these corresponding types shall also provide the
    > > > other.

    > >
    > > It says that if that _both_ uint32_t and int32_t exist,
    > > they must be corresponding types. It does not say the
    > > presence of uint32_t requires the corresponding signed
    > > integer to be two's complement and without padding.

    >
    > intN_t is *required* to be two's complement and without
    > padding bits.


    Perhaps I should have been clearer. I meant the
    corresponding type under 6.2.5. An int must have a
    corresponding unsigned int under 6.2.5. Similarly intN_t
    must have a corresponding unsigned integer type under
    6.2.5. That does not imply that intN_t's corresponding
    integer type under 6.2.5 meets the criteria for uintN_t.

    7.18.1p1 does not say that intN_t implies the presence of
    uintN_t and vice versa. It say that if both exist,
    then their corresponding types under 6.2.5 must be each
    other.

    If only one of intN_t or uintN exist for a given N,
    7.18.1p1 does not apply.

    --
    Peter
     
    Peter Nilsson, Sep 3, 2008
    #13
  14. On Sep 2, 6:34 pm, Peter Nilsson <> wrote:
    > Robert Gamble <> wrote:
    > > Peter Nilsson <> wrote:
    > > > Harald van D©¦k <> wrote:
    > > > > Pranav wrote:
    > > > > > typedef int R1;
    > > > > > unsigned R1 n1;

    >
    > > > > typedefs are not macros. You defined R1 as a typedef
    > > > > for (signed) int. You cannot make it unsigned later.

    >
    > > > Hence why <stdint.h> typedefs uintN_t as well as intN_t.
    > > > Note that a C99 implementation with CHAR_BIT == 32 must
    > > > provide uint32_t, but it need not provide int32_t.

    >
    > > If the implementation provides 32-bit integers without
    > > padding bits and uses two's complement representation,

    >
    > Let's say it does. Let's suppose int32_t is signed int.
    >
    > > both uint32_t and int32_t must be provided,

    >
    > I see nothing preventing the corresponding unsigned
    > int from having the range 0..INT_MAX.
    >
    > > otherwise neither shall be provided; in no case can
    > > one be provided without the other (7.18.1p1).

    >
    > If both exist, they must be corresponding types. That
    > does not imply that if one meets the relevant criteria
    > of an exact width integer type, so must the other.


    I fail to see how what you wrote above has any impact on what the
    standard says:

    7.18.1p1:
    "When typedef names differing only in the absence or presence of the
    initial u are defined,
    they shall denote corresponding signed and unsigned types as described
    in 6.2.5;
    an implementation providing one of these corresponding types shall
    also provide the other."

    I don't know how this could be any clearer. This requirement was
    referenced in DR 269 by Clive Feather:
    "...it can be derived from the requirement to provide both or neither
    of these types..."
    and there was no contradictory comment in the Committee Response.

    Can you provide any normative text that contradicts this?

    --
    Robert Gamble
     
    Robert Gamble, Sep 3, 2008
    #14
    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. Joona I Palaste

    Error in typedef

    Joona I Palaste, Feb 17, 2004, in forum: C Programming
    Replies:
    4
    Views:
    415
    Aleks
    Feb 18, 2004
  2. M. Faust
    Replies:
    0
    Views:
    392
    M. Faust
    Oct 18, 2004
  3. Generic Usenet Account
    Replies:
    3
    Views:
    824
    Generic Usenet Account
    Jul 14, 2005
  4. Replies:
    1
    Views:
    411
    msalters
    Aug 4, 2005
  5. oor
    Replies:
    0
    Views:
    1,356
Loading...

Share This Page