#define c bug in compilation

[polettix]

This simple program fails to compile in the 1.0.5 IDE:

#define c 42
void setup () {}
void loop () {}

I saw that the problem is with the c, nothing wrong happens using another token like d or life. Additionally, compilation is fine if there is a statement before the define, like in the following:

int a = 0;
#define c 42
void setup () {}
void loop () {}

I got the error while trying to compile the first sketch in http://www.arduino.cc/en/Tutorial/PlayMelody

[matthijskooijman]

My first guess is that the #include <Arduino.h> is inserted by the compiler after your #define, which makes every c in the ARduino header files replaced by 42. I think the proper solution would be to "Just don't do that, then..."

[polettix]

That might be the proper solution, but I think that it should at least be documented. Additionally, it would be helpful to find out what else might break things like #define c whatever does, and update the bare bones sketch so that this kind of problems is avoided (like putting a dummy int protection_for_includes = 0; at the very beginning, indicating that it should be left in place).

[jantje]

It is documented here: http://en.wikipedia.org/wiki/C_preprocessor
To put it simple adding "#define c what ever" to the top of a source file is the same as global find and replace "c" with "what ever"
so
int access;
becomes
int awhat everwhat everess;

For any person with some experience writing C/C++ code adding "#define c whatever" to any c/c++ code is like driving drunk:

1. Don't do it.
2. If you do it anyway; keep quiet about it.
3. if you have done it anyway and it went wrong => don't moan

[polettix]

@jantje:

$ cat prova.c
#define c what ever
int access;
$ gcc -E -P prova.c

int access;

We agree that someone is drunk here, and please leave the driver's seat.

[ffissore]

I think "c" chars get replaced only if they are identified as single tokens

$ cat prova.c 
#define c whatever
int access;
void test(int c) {}
$ gcc -E -P prova.c 

int access;
void test(int whatever) {}

[jantje]

It used to be a simple find and replace but nowadays it is a token find and replace.
That is one of the drawbacks of getting old.

Anyways even with the token replacement all these will not work

// WCharacter.h prototypes
inline boolean isAlphaNumeric(int c) attribute((always_inline));
inline boolean isAlpha(int c) attribute((always_inline));
inline boolean isAscii(int c) attribute((always_inline));
inline boolean isWhitespace(int c) attribute((always_inline));
inline boolean isControl(int c) attribute((always_inline));
inline boolean isDigit(int c) attribute((always_inline));
inline boolean isGraph(int c) attribute((always_inline));
inline boolean isLowerCase(int c) attribute((always_inline));
inline boolean isPrintable(int c) attribute((always_inline));
inline boolean isPunct(int c) attribute((always_inline));
inline boolean isSpace(int c) attribute((always_inline));
inline boolean isUpperCase(int c) attribute((always_inline));
inline boolean isHexadecimalDigit(int c) attribute((always_inline));
inline int toAscii(int c) attribute((always_inline));
inline int toLowerCase(int c) attribute((always_inline));
inline int toUpperCase(int c)attribute((always_inline));

[jantje]

just for the fun of it here are the "bad" single small case chars giving problems
c h l n p s w
I'm actually pretty impressed with how small the list is. I had expected j and i which are very often used as iterator.
The reason is: the define is only "valid" for the headers and ino sketch.
If you could define for all the code then the list would be lots longer.

[ffissore]

@polettix do you think we may close this issue?

[polettix]

@ffissore sincerely I don't think. It seems that this is something happening due to some "auto-magic" insertion of stuff in the beginning of the code, but I haven't seen any reference in the docs. If there is no way to avoid this error, I think it might be at least useful to document it.

Of course this is only my opinion! :-)

Ciao.