Macro constants

Discussion in 'C Programming' started by Ioannis Vranos, Apr 4, 2008.

  1. ==> C90:


    Errata for K&R2 page 232 (from
    http://www-db-out.research.bell-labs.com/cm/cs/cbook/2ediffs.html):\


    232(§A12.5): The result of the defined operator is not replaced
    literally by 0L or 1L, nor are undefined names literally by 0L, but just
    by plain 0 or 1. However, the constant expression is nevertheless
    evaluated as if these and *other constants* appearing have long or
    unsigned long type.


    When it mentions "these and other constants", what are the other
    constants implied?
    Ioannis Vranos, Apr 4, 2008
    #1
    1. Advertising

  2. Ioannis Vranos

    Thad Smith Guest

    Ioannis Vranos wrote:

    > Errata for K&R2 page 232 (from
    > http://www-db-out.research.bell-labs.com/cm/cs/cbook/2ediffs.html):\
    >
    >
    > 232(§A12.5): The result of the defined operator is not replaced
    > literally by 0L or 1L, nor are undefined names literally by 0L, but just
    > by plain 0 or 1. However, the constant expression is nevertheless
    > evaluated as if these and *other constants* appearing have long or
    > unsigned long type.
    >
    >
    > When it mentions "these and other constants", what are the other
    > constants implied?


    That would certainly include the user literals, such as 2 in

    #if X > 2

    --
    Thad
    Thad Smith, Apr 4, 2008
    #2
    1. Advertising

  3. Thad Smith wrote:
    > Ioannis Vranos wrote:
    >
    >> Errata for K&R2 page 232 (from
    >> http://www-db-out.research.bell-labs.com/cm/cs/cbook/2ediffs.html):\
    >>
    >>
    >> 232(§A12.5): The result of the defined operator is not replaced
    >> literally by 0L or 1L, nor are undefined names literally by 0L, but just
    >> by plain 0 or 1. However, the constant expression is nevertheless
    >> evaluated as if these and *other constants* appearing have long or
    >> unsigned long type.
    >>
    >>
    >> When it mentions "these and other constants", what are the other
    >> constants implied?

    >
    > That would certainly include the user literals, such as 2 in
    >
    > #if X > 2



    So when

    #define SOMETHING 6

    is used, the 6 is considered as long or unsigned long?



    Also I can't understand the following sentence completely:


    "However, the constant expression"

    I suppose it means the expression


    defined identifier

    or

    defined ( identifier)



    "is nevertheless evaluated as if these and other constants"


    Which constants does it mean with "these", and which constants does it
    mean with "other"?


    "appearing have long or unsigned long type".
    Ioannis Vranos, Apr 4, 2008
    #3
  4. In article <ft3uhg$20o2$>,
    Ioannis Vranos <> wrote:

    >Also I can't understand the following sentence completely:


    >"However, the constant expression"


    >I suppose it means the expression


    >defined identifier


    >or


    >defined ( identifier)


    Yes.


    >"is nevertheless evaluated as if these and other constants"


    >Which constants does it mean with "these",


    The 0 or 1 that results from evaluating the 'defined' operator.

    >and which constants does it
    >mean with "other"?


    User literal numbers, macros that expand to user literal numbers.

    >"appearing have long or unsigned long type".


    If a literal constant without a suffix is greater than LONG_MAX then it
    will be treated as unsigned. I believe everything else follows from the
    usual promotion rules for mixing signed and unsigned values -- so if you
    add two large unsuffixed numeric literals each less than LONG_MAX,
    that would be a signed operation, with overflow a possibility
    I believe (it is a constraint violation to evaluate to something
    that is outside the representable range for the type, due to
    the #if processing of constant expressions to be done the same way
    as for constant expressions in normal text, and the appropriate
    section of the standard for that has a "shall" clause requiring
    keeping within the representable range.)
    --
    This is a Usenet signature block. Please do not quote it when replying
    to one of my postings.
    http://en.wikipedia.org/wiki/Signature_block
    Walter Roberson, Apr 4, 2008
    #4
  5. Walter Roberson wrote:
    > In article <ft3uhg$20o2$>,
    > Ioannis Vranos <> wrote:
    >
    >> Also I can't understand the following sentence completely:

    >
    >> "However, the constant expression"

    >
    >> I suppose it means the expression

    >
    >> defined identifier

    >
    >> or

    >
    >> defined ( identifier)

    >
    > Yes.
    >
    >
    >> "is nevertheless evaluated as if these and other constants"

    >
    >> Which constants does it mean with "these",

    >
    > The 0 or 1 that results from evaluating the 'defined' operator.
    >
    >> and which constants does it
    >> mean with "other"?

    >
    > User literal numbers, macros that expand to user literal numbers.
    >
    >> "appearing have long or unsigned long type".

    >
    > If a literal constant without a suffix is greater than LONG_MAX then it
    > will be treated as unsigned. I believe everything else follows from the
    > usual promotion rules for mixing signed and unsigned values -- so if you
    > add two large unsuffixed numeric literals each less than LONG_MAX,
    > that would be a signed operation, with overflow a possibility
    > I believe (it is a constraint violation to evaluate to something
    > that is outside the representable range for the type, due to
    > the #if processing of constant expressions to be done the same way
    > as for constant expressions in normal text, and the appropriate
    > section of the standard for that has a "shall" clause requiring
    > keeping within the representable range.)



    I didn't understand the above. User literal integer numbers without a
    suffix are considered as ints.


    The text mentions that "However, the constant expression is nevertheless
    evaluated as if these and other constants appearing have long or
    unsigned long type", not int or unsigned int.


    I suppose it means that when we have:


    #define WHATEVER 123


    #if defined (WHATEVER)


    in defined statement, the WHATEVER is considered as long or unsigned
    long, but I am not sure if this is what it means.
    Ioannis Vranos, Apr 4, 2008
    #5
  6. Ioannis Vranos <> writes:
    <snip>
    > User literal integer numbers without a
    > suffix are considered as ints.
    >
    > The text mentions that "However, the constant expression is nevertheless
    > evaluated as if these and other constants appearing have long or
    > unsigned long type", not int or unsigned int.
    >
    > I suppose it means that when we have:
    >
    > #define WHATEVER 123
    >
    > #if defined (WHATEVER)
    >
    > in defined statement, the WHATEVER is considered as long or unsigned
    > long, but I am not sure if this is what it means.


    No, it is talking about two things:

    (1) the replacement of defined(WHATEVER) by 1
    (2) any other constants that might be there.

    When WHATEVER appears *on its own* in an #if expression it will be
    replaced by 123 and *that* constant will be considered to be long, but
    the text you quote is talking about defined(WHATEVER). The whole
    defined(WHATEVER) is replaced by 1 and it is that 1 that is considered
    to be long, not int.

    In this example:

    #if defined(WHATEVER) + defined(NOT_DEFINED_ANYWHERE) + 32 + WHATEVER

    there are three substitutions:

    defined(WHATEVER) => 1
    defined(NOT_DEFINED_ANYWHERE) => 0
    WHATEVER => 123

    and one "other constant" 32. All of these are to be considered as
    having long or unsigned long type.

    --
    Ben.
    Ben Bacarisse, Apr 4, 2008
    #6
  7. Ben Bacarisse wrote:
    > Ioannis Vranos <> writes:
    > <snip>
    >> User literal integer numbers without a
    >> suffix are considered as ints.
    >>
    >> The text mentions that "However, the constant expression is nevertheless
    >> evaluated as if these and other constants appearing have long or
    >> unsigned long type", not int or unsigned int.
    >>
    >> I suppose it means that when we have:
    >>
    >> #define WHATEVER 123
    >>
    >> #if defined (WHATEVER)
    >>
    >> in defined statement, the WHATEVER is considered as long or unsigned
    >> long, but I am not sure if this is what it means.

    >
    > No, it is talking about two things:
    >
    > (1) the replacement of defined(WHATEVER) by 1
    > (2) any other constants that might be there.
    >
    > When WHATEVER appears *on its own* in an #if expression it will be
    > replaced by 123 and *that* constant will be considered to be long, but
    > the text you quote is talking about defined(WHATEVER). The whole
    > defined(WHATEVER) is replaced by 1 and it is that 1 that is considered
    > to be long, not int.
    >
    > In this example:
    >
    > #if defined(WHATEVER) + defined(NOT_DEFINED_ANYWHERE) + 32 + WHATEVER
    >
    > there are three substitutions:
    >
    > defined(WHATEVER) => 1
    > defined(NOT_DEFINED_ANYWHERE) => 0
    > WHATEVER => 123
    >
    > and one "other constant" 32. All of these are to be considered as
    > having long or unsigned long type.



    In the #define SOMETHING 123 case, 123 is considered int or long where
    it substitutes SOMETHING, like in

    int array[SOMETHING]; ?
    Ioannis Vranos, Apr 4, 2008
    #7
  8. Ioannis Vranos writes:
    > So when
    > #define SOMETHING 6
    > is used, the 6 is considered as long or unsigned long?


    In preprocessor arithmetic in C89, yes. 6 is considered long since it
    fits in a long. 4000000000 does not fit in a long but fits in an
    unsigned long if long is 32-bit, so it is treated as unsigned long.

    The idea is that preprocessor arithmetic is done in the largest standard
    integer type available. So C89 compilers use long or unsigned long,
    while C99 compilers use intmax_t or uintmax_t (which is at least as wide
    as long long).

    C89 compilers which support long long as an extension (except I'm not
    sure that's strictly speaking a C89 compiler) can complicate this -
    obviously "long long" constants should not be truncated to "long".
    The most natural solution would be the usual arithmetic conversions -
    e.g. ULONG_MAX + 1 == 0L but ULONG_MAX + 1LL promotes ULONG_MAX to
    long long so the result is 0x100000000LL or whatever.

    --
    Hallvard
    Hallvard B Furuseth, Apr 4, 2008
    #8
  9. Ioannis Vranos <> writes:

    > Ben Bacarisse wrote:
    >> Ioannis Vranos <> writes:
    >> <snip>
    >>> User literal integer numbers without a
    >>> suffix are considered as ints.
    >>>
    >>> The text mentions that "However, the constant expression is nevertheless
    >>> evaluated as if these and other constants appearing have long or
    >>> unsigned long type", not int or unsigned int.
    >>>
    >>> I suppose it means that when we have:
    >>>
    >>> #define WHATEVER 123
    >>>
    >>> #if defined (WHATEVER)
    >>>
    >>> in defined statement, the WHATEVER is considered as long or unsigned
    >>> long, but I am not sure if this is what it means.

    >>
    >> No, it is talking about two things:
    >>
    >> (1) the replacement of defined(WHATEVER) by 1
    >> (2) any other constants that might be there.
    >>
    >> When WHATEVER appears *on its own* in an #if expression it will be
    >> replaced by 123 and *that* constant will be considered to be long, but
    >> the text you quote is talking about defined(WHATEVER). The whole
    >> defined(WHATEVER) is replaced by 1 and it is that 1 that is considered
    >> to be long, not int.
    >>
    >> In this example:
    >>
    >> #if defined(WHATEVER) + defined(NOT_DEFINED_ANYWHERE) + 32 + WHATEVER
    >>
    >> there are three substitutions:
    >>
    >> defined(WHATEVER) => 1
    >> defined(NOT_DEFINED_ANYWHERE) => 0
    >> WHATEVER => 123
    >>
    >> and one "other constant" 32. All of these are to be considered as
    >> having long or unsigned long type.

    >
    >
    > In the #define SOMETHING 123 case, 123 is considered int or long where
    > it substitutes SOMETHING, like in
    >
    > int array[SOMETHING]; ?


    No. All of this discussion has been only about how expressions behave
    in the pre-processor. Once SOMETHING is replaced by the token 123 in
    normal code, it's meaning is defined by the rest of the C standard.

    --
    Ben.
    Ben Bacarisse, Apr 4, 2008
    #9
    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. Dead RAM
    Replies:
    20
    Views:
    1,074
    John Harrison
    Jul 14, 2004
  2. D Senthil Kumar

    macro name from macro?

    D Senthil Kumar, Sep 20, 2003, in forum: C Programming
    Replies:
    1
    Views:
    555
    Jack Klein
    Sep 21, 2003
  3. Mark Richards

    Macro or eval() for constants at runtime?

    Mark Richards, Jan 21, 2005, in forum: C Programming
    Replies:
    2
    Views:
    289
    Mark Richards
    Jan 21, 2005
  4. sounak

    to get macro name from macro value

    sounak, Nov 22, 2005, in forum: C Programming
    Replies:
    17
    Views:
    476
    Mark McIntyre
    Nov 22, 2005
  5. Richard Meister

    Howto check value of constants in a macro

    Richard Meister, Nov 22, 2005, in forum: C Programming
    Replies:
    11
    Views:
    445
    Michael Mair
    Nov 23, 2005
Loading...

Share This Page