Skip to content

#define c bug in compilation #1735

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
polettix opened this issue Dec 13, 2013 · 12 comments
Closed

#define c bug in compilation #1735

polettix opened this issue Dec 13, 2013 · 12 comments
Labels
Component: Documentation Related to Arduino's documentation content

Comments

@polettix
Copy link

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
Copy link
Collaborator

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
Copy link
Author

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
Copy link

jantje commented Dec 14, 2013

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
Copy link
Author

@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
Copy link
Contributor

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
Copy link

jantje commented Dec 15, 2013

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
Copy link

jantje commented Dec 15, 2013

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
Copy link
Contributor

@polettix do you think we may close this issue?

@ghost ghost assigned ffissore Dec 19, 2013
@polettix
Copy link
Author

@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.

@ffissore
Copy link
Contributor

Please checkout this thread [1] on devs mailing list and try one of the linked IDEs. It should fix the problems reported in this issue
[1] https://groups.google.com/a/arduino.cc/forum/#!topic/developers/4X2T3rCxXWM

@polettix
Copy link
Author

I'll take a look and provide some feedback. Thanks for caring!

2015-01-21 11:04 GMT+01:00 Federico Fissore [email protected]:

Please checkout this thread [1] on devs mailing list and try one of the
linked IDEs. It should fix the problems reported in this issue
[1]
https://groups.google.com/a/arduino.cc/forum/#!topic/developers/4X2T3rCxXWM


Reply to this email directly or view it on GitHub
#1735 (comment).

@agdl
Copy link
Member

agdl commented Apr 3, 2015

@polettix are there any news about this?

@agdl agdl added the Waiting for feedback More information must be provided before we can proceed label Apr 3, 2015
@cmaglie cmaglie removed the Waiting for feedback More information must be provided before we can proceed label Oct 18, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Component: Documentation Related to Arduino's documentation content
Projects
None yet
Development

No branches or pull requests

6 participants