John (Eljay) Love-Jensen wrote:
Hi Yang Zhang,
But is there any workaround for this problem in general, where the source of
the problem is a macro defined in a system header? I'm seeing the same problem
with FD_SET, FD_ISSET, etc.
Well... I did provide a general workaround.
What I really intended to ask: is there any hope of seeing GCC not issue
warnings for expansions of macros that were defined in a C standard
library, such that users don't need to read through and re-define these
C standard library macros? I understand what's going on and I
understand your suggested workaround. Indeed it may be the only
workaround for now, but I hope you'll agree that it's less than ideal.
Realization of this seems slightly tricky since there is no 1:1 mapping
between line numbers and macro expansions, so the preprocessor can't
help pinpoint original location of the macro definition. Perhaps having
the preprocessor emit some sort of *in-line* source line number
annotation would be the simplest approach to enable the compiler to
ignore these:
__line__("<original header file>", <line no>, <expanded macro>)
Another solution presented by someone on this forum many years ago is to use
a tool like Perl (Python, Ruby, or even sed) to filter the output from the
warnings deemed benign which you don't want to see. Perhaps this approach
is a more suitable general workaround.
This doesn't work with -Werror.
--
Yang Zhang
http://www.mit.edu/~y_z/
