Opened 10 years ago
Closed 10 years ago
#536 closed defect (fixed)
GCC_VERSION should not be defined in the header file
Reported by: | Marcin Sobieszczanski | Owned by: | Alpar Juttner |
---|---|---|---|
Priority: | major | Milestone: | LEMON 1.4 release |
Component: | core | Version: | hg main |
Keywords: | Cc: | ||
Revision id: |
Description
lemon/core.h (re-)defines GCC_VERSION that is visible to all files that include LEMON headers.
In case a user project uses lemon/core.h (indirectly) and defines its own GCC_VERSION tag (that isn't compatible with LEMON's definition -- GCC_VERSION isn't reserved), this causes a warning that cannot be suppressed. And so warning elevation cannot be used (-Werror).
IMHO, LEMON should defer from (re-)defining its own GCC_VERSION. I suggest the following patch:
--- lemon/core.h.orig 2014-11-24 10:29:17.996837046 +0000 +++ lemon/core.h 2014-11-24 10:32:41.471925566 +0000 @@ -37,13 +37,7 @@
#pragma warning( disable : 4250 4355 4503 4800 4996 ) #endif
-#ifdef GNUC -#define GCC_VERSION (GNUC * 10000 \
- + GNUC_MINOR * 100 \
- + GNUC_PATCHLEVEL)
-#endif - -#if GCC_VERSION >= 40800
(GNUC == 4 && GNUC_MINOR >= 8) |
Needed by the [DI]GRAPH_TYPEDEFS marcos for gcc 4.8 #pragma GCC diagnostic ignored "-Wunused-local-typedefs" #endif
Attachments (1)
Change History (5)
Changed 10 years ago by
Attachment: | gcc-version.patch added |
---|
comment:1 Changed 10 years ago by
comment:2 Changed 10 years ago by
Thanks for the path.
What if we still defined LEMON_GCC_VERSION
? It might be clearer if gcc version is checked at multiple places. Though I'm uncertain whether we will ever use it again.
The 'major' priority is to be read as 'normal' or 'default', so it is just fine.
comment:3 Changed 10 years ago by
LEMON_GCC_VERSION would work for me. It is still one extra symbol visible to the users of the library (and in fact it doesn't solve the original problem, just makes it less probable -- under assumption that LEMON_GCC_VERSION is less probable than GCC_VERSION...). This could entirely be avoided by not defining the symbol and using gcc macros directly (like in the patch I sent you).
comment:4 Changed 10 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
The patch is applied as [1d80ec7d17eb]. Thanks for the contribution.
I didn't want to create the ticket with major priority (my oversight); I don't know how to change it now.
The patch seems not to be displayed correctly, so attaching it in a file.