> I'll think about it and check my ISO C 1989 standard (I can't remember
> whether it supports %p) when I get back to work on Tuesday.
ANSI C '89 does specify the %p formatter (taking a void*).
> Finally, it seems that some of these changes are meant to avoid variable
> names conflicting with function names (open, etc.) Is this really a warning
> that some compilers give?
Even gcc has a flag for it: -Wshadow; I conjecture that the submitter
is using more aggressive warning flags than you ... I believe -Wshadow
is not part of what's normally enabled by use of -Wall -Wextra, which
I tend to prefer (trusting the judgement of the gcc team).
Submitter: what warning flags are you passing to gcc ?
> I've never seen that warning, and it sure seems to me like it would
> be almost impossible to write a portable C program that didn't hit
> that warning, since every C runtime defines a horde of functions and
> there is no way to know what they all are.
The C '89 spec specifies (section 4.1.2.1) some namespace rules that
should obviate such problems: roughly speaking, names starting _
should not be used by the application and some classes of them are
reserved to the implementation (including standard library); so, as
long as the standard library sticks to those classes of names (for the
symbols it uses internally), there should be no problem.
The commonest violation of the reserved identifier rules that I've
seen is folk whose choice of identifier to #ifndef and #define in a
header, to protect against multiple inclusion, begins with an
underscore, e.g. protecting blah.h (in a mylib package) with <bad>
#ifndef _MYLIB_BLAH_H_
#define _MYLIB_BLAH_H_
...
#endif
</bad> violates the rules, unless blah.h is part of the standard
library. Ditch those leading underscores ! (... and, on aesthetic
grounds, the trailing ones.) None the less, this is seldom implicated
in a shadowing warning.
> I don't like it.
I can sympathise. I have, however, seen warnings (possibly from gcc,
but perhaps a Sun compiler) against the use of "index" as a variable
(it's an old name for what eventually got standardised as one of the
library functions, I suspect strchr or bsearch but can't remember),
probably on Slowlaris years ago.
The answer may be to declare an overt policy on what gcc warning flags
you actually care about and explicitly say that you aren't interested
in warnings that can be obtained by more aggressive warning settings.
All things considered, some of gcc's -W... flags are pretty esoteric.
Eddy.
_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make
