Closed GoogleCodeExporter closed 9 years ago
Trying to reproduce this issue to fully understand it...
Original comment by guillermocalvo
on 16 Mar 2014 at 7:00
I'm using "MinGW GCC 4.8.1 32-bit Release" and it works nicely.
Which MinGW version are you using? Could you please show me the compiler log?
Thanks in advance :)
Original comment by guillermocalvo
on 16 Mar 2014 at 7:37
It seemed to also disappear for me now with Ubuntu's packaged MinGW-w64.
However, when I downloaded the latest snapshots of MinGW-w64 from their
website, it failed there.
This might be a very rare bug, but I see no harm in putting this in just to
make sure it won't fail with some weird compilers...
Original comment by tal.liron
on 16 Mar 2014 at 7:41
Problem is I'm not sure if `#define E4C_USE()` is a legal macro definition :-/
Original comment by guillermocalvo
on 16 Mar 2014 at 7:49
[deleted comment]
Oh, I'm sure it is! At least, I use that format all the time. Here's another
opinion:
http://stackoverflow.com/questions/4251005/what-is-the-difference-between-a-c-pr
eprocessor-macro-with-no-arguments-and-o
Original comment by tal.liron
on 16 Mar 2014 at 7:53
Honestly, it doesn't feel right to me replacing a valid macro definition for
another, simply to avoid a rare compiler bug :(
Even if macros with zero arguments seem to work on most compilers, portability
could be compromised (exceptions4c intends to be ANSI C compatible), although I
should test it on old compilers to be sure.
In addition, for the sake of coherence I would be forced to replace every macro
definition: FOO => FOO()
Therefore, as long as this issue keeps being a rarity that occurs only with
certain versions of MinGW, I think I'm just going to leave it as it is.
Thanks for your understanding.
Original comment by guillermocalvo
on 16 Mar 2014 at 11:31
Sure. I will keep a patched version for my needs.
Original comment by tal.liron
on 16 Mar 2014 at 11:33
Original issue reported on code.google.com by
tal.liron
on 12 Mar 2014 at 7:55