Skip to content

User #define clashes with automatically added headers #2289

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
a3f opened this issue Sep 7, 2014 · 3 comments
Closed

User #define clashes with automatically added headers #2289

a3f opened this issue Sep 7, 2014 · 3 comments

Comments

@a3f
Copy link

a3f commented Sep 7, 2014

A sketch with this line here
#define s1 42
doesn't compile because it breaks the prototype at avr/include/string.h:129
extern char *strdup(const char *s1);
.
I don't use Arduino but I think s1 is not supposed to be a reserved identifier.
My suggestion would be using __s1 or_S1. I am not familiar enough with the app to suggest (let alone commit) a different order of processing the Arduino sketch to C++.

@a3f a3f changed the title User #define's clashing with automatically added headers User #define clashes with automatically added headers Sep 7, 2014
@matthijskooijman
Copy link
Collaborator

This is a problem with macros - if you use them you should use sufficiently long identifiers to prevent conflicts. Alternatively, you can use constants, which are properly parsed and scoped by the compiler, so are less powerful, bug also more reliable:

const int s1 = 42;

@matthijskooijman
Copy link
Collaborator

In any case, this is not a problem caused by, or fixable in Arduino, so I'm closing this issue.

@a3f
Copy link
Author

a3f commented Sep 8, 2014

I beg to differ. That's not a problem with macros, but with the fact that the macros are inserted before the automatically added headers, which is something caused by Arduino.
This might be useful for #define'ing NDEBUG when using assertions for example but that doesn't justify breaking conformant code.

As for the fixable part using __s1 or _S1 should do the trick, as they are reserved for implementation use anyway.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants