A patch to constify gcc.c (Really, summarizing remaining warnings)

[Zack Weinberg]

On Wed, 10 Mar 1999 22:22:17 -0500 (EST), "Kaveh R. Ghazi" wrote:
>	Okay, I'll summarize the remainder of -W -Wall a bit.
[...]
>5.  20 statement with no effect
>
>	These are all due to intl calls to `bindtextdomain' and
>`textdomain'.  In intl/libintl.h, these are defined to "((char *)
>Domainname)" which gives the above warning.  We could probably get rid
>of it by casting these to (void) at the site of each call.

Since we never ever use the result of bindtextdomain or textdomain, we
could also define these functions to a void expression in
intl/libintl.h.  This would be much less invasive but might be
excessively sneaky for some people's taste, since the real functions
do return a value.

>6.  25-35 implicit declaration of function `putc_unlocked'
>
>	These have been discussed, but I don't believe I ever heard a
>satisfactory solution posted.  See
> http://www.cygnus.com/ml/egcs/1999-Jan/0361.html

There appear to be three related problems:

- Sometimes the functions are not prototyped unless _REENTRANT is
defined.  In that case we don't need to use them, since plain
putc/getc are equivalent when _REENTRANT is not defined.  We should
use GCC_NEED_DECLARATION if we see the functions in the library, and
if they aren't prototyped, ignore them.

- Sometimes the functions are only macros.  We would need to use
something like AC_EGREP_CPP to figure out if macro definitions are
present.  This would be ugly.  These systems deserve to lose IMO; it's
a design principle of the C library that you can do (func)(args...) to
suppress a macro, and it'll work (with a very few exceptions).

- fputs_unlocked is also used if available.  This one is a GNU
extension, and glibc 2.x doesn't prototype it unless you define
_GNU_SOURCE.  I sent in a patch for system.h earlier today that
defines _GNU_SOURCE if HAVE_FPUTS_UNLOCKED is defined.  I believe this
to be safe; however, it does pull in an immense amount of other stuff,
and if the BSDs pick up fputs_unlocked, it may stop working.

>7a.  9 variable `???' might be clobbered by `longjmp' or `vfork'
>7b.  5 argument `???' might be clobbered by `longjmp' or `vfork'
>
>	(A bit more of these also occur in the cp/ and java/ dirs.)
>
>I don't know how we could fix these.  Perhaps one could make the
>parameter or variable volatile, but it doesn't really fix the problem
>and it seems to just provoke the warning on another variable. (?)

Where do we use longjmp and vfork?  Are they necessary?

>	That's about it.  Each platform has about 10 or less stray
>warnings beyond the above which we could squash when we get the bulk
>of the remaining ones.  I hope others would help out with this since
>I'm kind of tired of doing it. :-)

I sent a patch for some of these several weeks ago and got no
comments.  There was a possible bug in there: i386.h defines
ASM_OPEN_PAREN and ASM_CLOSE_PAREN to the empty string.  No one else
does this. I could imagine the assembler getting precedences
wrong without any parentheses.  Is it really correct?

Patch was http://egcs.cygnus.com/ml/egcs-patches/1999-02/msg00364.html .

zw