Re: patch to suggest putc/fputs over printf("string") or printf("\n")

[Ulrich Drepper <drepper at cygnus dot com>]

"Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> writes:

> 	I'd be interested in seeing the example.  The URL Jeff provided
> said it was legal for ANSI C.  It could be wrong, but I'd like to see
> why. 

OK, remember, this is for gcc.  We have special attributes for
functions like gettext.  Therefore

	printf (gettext ("some string `%s'"), 10)

would lead to a warning.  The gettext call is transparent and I expect
a warning about using printf instead of fputs for

	printf (gettext ("some constant string"))

But there are also situations where the replacement returned by a
gettext call with an argument without format specifiers contains
format specifiers.  A call could look like this:

	printf (gettext ("no format here"), some_variable)

The return value of the gettext call could be "value %d".

Now one can of course say this is not used.  I don't agree with this
since some of the gettext extensions which will come sometime will use
dirty tricks like this.  The other objections could be that the
gettext attribute should not be taken into account and therefore is
not replaced.  But this is completely against the purpose of this
attribute: if we user gets a warning s/he can look at the case and
decide whether the use of printf is necessary.  If the compiler simply
silently rejects this case and does not substitute fputs for printf
the programmer might never learn about the missed opportunity for an
optimization.

A possibility is of course to perform automatic conversion in the case
where no such problem exists and warn in the other case (when using
gettext etc).  But this is IMO too inconsistent, better always go with
the warning and let the programmer decide.  In this situation it is
necessary, though, to have a way to shut up the compiler if the way
the code is written is correct.  Somebody said #pragma?

-- 
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------