[Bug preprocessor/64220] New: gcc preprocessor defines outside of the reserved namespace: unix linux AVR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64220 Bug ID: 64220 Summary: gcc preprocessor defines outside of the reserved namespace: unix linux AVR Product: gcc Version: 4.9.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: cameron at tacklind dot com The preprocessor defines names outside of the reserved namespace. Essentially, if I'm not mistaken, the following command should output nothing # gcc -dM -E - < /dev/null | grep -v '^#define _[_A-Z]' However, for historical reasons, the preprocessor defines things like "unix" and "linux" or "AVR" (with avr-gcc). I'm sure other show up on other systems that I have not tested. This has been referenced slightly in #2069, but the solution there was to just manually un-define (-U) the extra define. (Which I'll do if I have to) This is also talked about briefly in the documentation where it suggest better alternatives like __unix__ et al. It even says "The C standard requires that all system-specific macros be part of the reserved namespace." https://gcc.gnu.org/onlinedocs/cpp/System-specific-Predefined-Macros.html Could these defines outside of the reserved namespace be removed? Or deprecated now (if they aren't already?) and removed in 5.0? Or are those defines here to stay for historical reasons?
[Bug preprocessor/64220] gcc preprocessor defines outside of the reserved namespace: unix linux AVR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64220 --- Comment #2 from Cameron Tacklind --- Ah, I had not seen a reference to the -std making a difference. You are right that adding -std=c99 removes the extra define. Of note, I'm finding it difficult to find where this behavior (the define being in gnuXX and not cXX) is described in the documentation. (But I may just be blind) If this is a desired define behavior, then by all means leave it and please close this as a "WONTFIX". I just wanted to bring this up, in particular, because I want to use AVR in a project I'm working on and I had not seen a good reason for its existence besides deprecated usage.
[Bug preprocessor/64220] gcc preprocessor defines outside of the reserved namespace: unix linux AVR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64220 --- Comment #5 from Cameron Tacklind --- Pardon my brevity. Yes, I'd seen that. I was trying to comment on this list seemingly missing a reference to that particular difference. Or that if it is listed, it is difficult to find. https://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html By my main issue persists of extra defines being set outside of the reserved namespace. If this is something that you do not want to change, I am fine with that. If so, please close this indicating that you want this behavior.
[Bug c/64347] New: constructor priorities are not supported in avr-gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64347
Bug ID: 64347
Summary: constructor priorities are not supported in avr-gcc
Product: gcc
Version: 4.9.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: cameron at tacklind dot com
In avr-gcc, if you try to add a priority to a constructor function, you get:
"error: constructor priorities are not supported"
Steps to reproduce:
# echo 'void init() __attribute__((constructor(TEST)));' > test.c
# echo 'int main() {return 0;}' >> test.c
Compiles with no errors
# gcc test.c -D TEST=1000
# avr-gcc test.c -D TEST=
Does not compile
# avr-gcc test.c -D TEST=1000
[Bug c/99720] New: Feature Request: Better errors for C++ features when compiling C (pass by reference)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99720 Bug ID: 99720 Summary: Feature Request: Better errors for C++ features when compiling C (pass by reference) Product: gcc Version: 9.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: cameron at tacklind dot com Target Milestone: --- I'm embarrassed that I spent so long on this issue, to the point that I thought it was worth writing this issue in the hope that it might save someone the same trouble. If this is inappropriate (or already address), my apologies. I normally work in the C++ world for simple embedded programming, mostly just with a subset of the language features. I love the sugar. The old "C" way of doing things has always bugged me. I'm thinking of basic features like overloading function. Now I'm working on a project that has a lot of legacy C that's too much work to convert to C++. In implementing a simple function, without thinking, I used a reference (`void foo(int&i);`) to pass a variable to a function (not a plain pointer). The astute among you will remember that passing by reference is a C++ feature that simply does not exist in C. Error message: > test.c:1:13: error: expected ‘;’, ‘,’ or ‘)’ before ‘&’ token It took me most of a day to realize I was trying to use a feature that simply doesn't exist in C (lots of other #define macros that contributed to my confusion). It feels like this error message should be easy enough to improve. With how often C and C++ get conflated, it seems prudent to me to ensure that accidentally using C++ features in a C compiler would generate warnings or errors that point towards these possible mistake explicitly.
