Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #11049 > unrolled thread

macro with the same name in translation unit

Back to article view | Back to comp.lang.c

Contents

  macro with the same name in translation unit "Mark" <mark_cruzNOTFORSPAM@hotmail.com> - 2011-09-28 10:53 -0400
    Re: macro with the same name in translation unit James Kuyper <jameskuyper@verizon.net> - 2011-09-28 11:41 -0400
      Re: macro with the same name in translation unit Keith Thompson <kst-u@mib.org> - 2011-09-28 09:22 -0700
        Re: macro with the same name in translation unit James Kuyper <jameskuyper@verizon.net> - 2011-09-28 13:16 -0400
          Re: macro with the same name in translation unit Keith Thompson <kst-u@mib.org> - 2011-09-28 13:42 -0700
            Re: macro with the same name in translation unit James Kuyper <jameskuyper@verizon.net> - 2011-09-28 17:18 -0400

#11049 — macro with the same name in translation unit

Hi,

consider the snippet:

#include <stdio.h>

#define DUMMY 100
#define FOO 200
#define DUMMY 200

int main (void)
{
    printf("%d, %d\n",FOO, DUMMY);
    return 0;
}

The compiler I'm using (gcc-4.1.2) emits warning message about redefined 
macro, but picks up and prints the last defined, i.e. with value 200. Is 
this platform dependent behavior, or undefined behavior?

Thanks.

Mark 

[toc] | [next] | [standalone]

#11052

On 09/28/2011 10:53 AM, Mark wrote:
> Hi,
> 
> consider the snippet:
> 
> #include <stdio.h>
> 
> #define DUMMY 100
> #define FOO 200
> #define DUMMY 200
> 
> int main (void)
> {
>     printf("%d, %d\n",FOO, DUMMY);
>     return 0;
> }
> 
> The compiler I'm using (gcc-4.1.2) emits warning message about redefined 
> macro, but picks up and prints the last defined, i.e. with value 200. Is 
> this platform dependent behavior, or undefined behavior?

6.103p2 says:
> An identifier currently defined as an object-like macro shall not be redefined by another
> #define preprocessing directive unless the second definition is an object-like macro
> definition and the two replacement lists are identical. ...

Both #defines of DUMMY define it as an object-like macro, but the
replacement lists are not identical. This "shall" occurs in a
Constraints section, so a diagnostic is required. The warning message
meets that requirement.

A conforming implementation of C is allowed, but not required, to accept
the code after issuing the diagnostic. If the code is accepted, the
behavior of the program when executed is not defined by the C standard.
gcc-4.1.2 apparently has chosen one of the two most obvious ways of
dealing with this situation: letting the the second value override the
first. The other most obvious way is to keep the value as 100. Either
option is permitted, as well as many other options that could be much
nastier. I do NOT recommend relying upon this behavior.

The following two alternatives don't violate that constraint, and have
behavior corresponding to the two "obvious ways" I mentioned above:

Option 1:
#ifdef DUMMY
#undef DUMMY
#endif
#define DUMMY 200

Option 2:
#ifndef DUMMY
#define DUMMY 200
#endif

[toc] | [prev] | [next] | [standalone]

#11054

James Kuyper <jameskuyper@verizon.net> writes:
[...]
> The following two alternatives don't violate that constraint, and have
> behavior corresponding to the two "obvious ways" I mentioned above:
>
> Option 1:
> #ifdef DUMMY
> #undef DUMMY
> #endif
> #define DUMMY 200
>
> Option 2:
> #ifndef DUMMY
> #define DUMMY 200
> #endif

Option 3:

#undef DUMMY
#define DUMMY 200

#undef does nothing if the macro isn't currently defined (though I
suppose some compilers might issue a warning).

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#11056

On 09/28/2011 12:22 PM, Keith Thompson wrote:
> James Kuyper <jameskuyper@verizon.net> writes:
> [...]
>> The following two alternatives don't violate that constraint, and have
>> behavior corresponding to the two "obvious ways" I mentioned above:
>>
>> Option 1:
>> #ifdef DUMMY
>> #undef DUMMY
>> #endif
>> #define DUMMY 200
>>
>> Option 2:
>> #ifndef DUMMY
>> #define DUMMY 200
>> #endif
> 
> Option 3:

This is more like Option 1a:

> #undef DUMMY
> #define DUMMY 200
> 
> #undef does nothing if the macro isn't currently defined (though I
> suppose some compilers might issue a warning).

I should have remembered that! I still have fond memories of pointing
out the same issue to Nick Maclauren nearly two decades ago. It was one
of the few times I ever successfully corrected him on any issue.

[toc] | [prev] | [next] | [standalone]

#11060

James Kuyper <jameskuyper@verizon.net> writes:
[...]
> I should have remembered that! I still have fond memories of pointing
> out the same issue to Nick Maclauren nearly two decades ago. It was one
> of the few times I ever successfully corrected him on any issue.

You mean Nick Maclaren?  8-)}

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#11061

On 09/28/2011 04:42 PM, Keith Thompson wrote:
> James Kuyper <jameskuyper@verizon.net> writes:
> [...]
>> I should have remembered that! I still have fond memories of pointing
>> out the same issue to Nick Maclauren nearly two decades ago. It was one
>> of the few times I ever successfully corrected him on any issue.
> 
> You mean Nick Maclaren?  8-)}

Yes. I even looked it up before posting, to make sure I was remembering
the right person, but I made the mistake of copying his name by hand,
rather than using cut-and-paste.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c

csiph-web