This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: "introduce no new bootstrap warning" criteria. was: Loop iv debugging, patch


[CC list brutally trimmed.]

On Sun, Jan 14, 2001 at 08:40:44AM -0500, Kaveh R. Ghazi wrote:
>  > From: Neil Booth <neil@daikokuya.demon.co.uk>
>  > 
>  > Geoff Keating wrote:-
>  > 
>  > > Or perhaps the macro expander should track which macros are defined in
>  > > system headers and not produce warnings for them?
>  > 
>  > I'm not a fan of this option at all.  The only warnings we can avoid
>  > this way are CPP warnings about the macro definition, which one
>  > would hope was valid anyway being in a system header.
>  > 
>  > When it comes to usage, it gets really hairy because the invocation of
>  > the macro could have come from other macros or macro arguments,
>  > recursively who is to know whether those tokens come from user code or
>  > system headers?  And to the front ends, tokens all look the same
>  > regardless of whence they came.
> 
> I'm not sure its as hairy as you suggest, Zack seemed to think it
> could be done.  See my previous posting on this topic which contains
> references to his opinions from August.
> http://gcc.gnu.org/ml/gcc/2001-01/msg00886.html

I think we can all agree that the ideal situation, from the user's
point of view, would be:

/* stdio.h */
#define printf(format, args...) fprintf(stdout, format, ##args)

/* user */
printf("string")

	-> No warning about C99 vararg semantics.
	   (If the varargs extension is used by a macro defined in a
	   system header, suppress the warning.)

/* limits.h */
#define UINT_MAX 4294967295U

/* user */
  if (expression involving UINT_MAX)

	-> No warning about 'U' not understood by K+R C.
	   (If the numeric token in question originated in a system
	   header, suppress the warning.)

/* string.h */
#define strcmp(a, b) /* monstrous horror */

/* user */
  qsort(array, elts, sizeof (char *), strcmp);

	-> No warning about function macro used in non-function context.
	   (If the function macro in question was defined in a system
	   header, suppress the warning.)

/* syslog.h */
extern void syslog(int, char *, ...)
	__attribute__ ((format (printf, 2, 3)));

/* user */

syslog(LOG_INFO, "i=%s", 34);

	-> Yes, -Wformat warning.
	(-Wformat pays no attention to the location of the prototype
	for the printflike function.)

But I do expect that implementing this would take substantial effort.
We'd need to implement tests for every individual warning to determine
whether we're warning about a construct in the code the user wrote.
That is not the same in general as not warning about constructs
composed of tokens from system headers; nor is it the same as
suppressing all warnings in system headers.  Notice that the
appropriate check is different in each context.

>  > Zack showed Ulrich how to fix glibc to avoid the warning, and was
>  > rudely brushed off.

To be fair to Ulrich, he explained in private mail that he wants the
error message when printf is used without arguments to be the same
with or without -O.

My personal opinion about glibc's clever macros is that they make the
generated code worse, and they should all go away.  [This one is
perhaps the least problematic.]  As such, I'm not particularly
interested in catering to them in cpp.

However, I think effort put into improving gcc's warning generation is
always effort well spent.  And that includes reducing the number of
false positives.

zw

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]