This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
enum and macro collision
- From: vijay nag <vijunag at gmail dot com>
- To: "gcc-help at gcc dot gnu dot org" <gcc-help at gcc dot gnu dot org>
- Date: Tue, 17 Jan 2017 16:33:43 +0530
- Subject: enum and macro collision
- Authentication-results: sourceware.org; auth=none
Hello Gcc,
I came across this nasty C code of an enumerator and a macro having
the same name. Although this is a buggy code, I found it surprising
that GCC compiles in one of the cases(snippet 1) while in the other
compiler flags an error(snippet 2). Would be interested to know why
the order of definitions/declarations matter and what C standards the
compiler is adhering to ?
Code snippet 1: The below snippet passes off as a benign case where
compiler doesn't throw any error.
cat foo.c
#include <stdio.h>
typedef enum FooTypes {
FOO = 1,
BAR = 2
} FooTypes;
#define FOO 0xDEADBEEF
int main()
{
FooTypes ftypes;
ftypes = FOO;
}
Compiler: -E -dD output
#undef vsnprintf
#define vsnprintf(str,len,format,ap) __builtin___vsnprintf_chk (str,
len, 0, __darwin_obsz(str), format, ap)
# 493 "/usr/include/stdio.h" 2 3 4
# 3 "a.c" 2
typedef enum FooTypes {
FOO = 1,
BAR = 2
} FooTypes;
#define FOO 0xDEADBEEF
int main()
{
FooTypes ftypes;
ftypes = 0xDEADBEEF;
}
Code snippet2: The compiler flags an error in this case.
cat a.c
#include <stdio.h>
#define FOO 0xDEADBEEF
typedef enum FooTypes {
FOO = 1,
BAR = 2
} FooTypes;
int main()
{
FooTypes ftypes;
ftypes = FOO;
}
Compiler: -E -dD output
#undef vsnprintf
#define vsnprintf(str,len,format,ap) __builtin___vsnprintf_chk (str,
len, 0, __darwin_obsz(str), format, ap)
# 493 "/usr/include/stdio.h" 2 3 4
# 3 "a.c" 2
#define FOO 0xDEADBEEF
typedef enum FooTypes {
0xDEADBEEF = 1,
BAR = 2
} FooTypes;
int main()
{
FooTypes ftypes;
ftypes = 0xDEADBEEF;
}