This is the mail archive of the
mailing list for the GCC project.
Re: A patch to constify gcc.c (Really, summarizing remaining warnings)
- To: "Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>
- Subject: Re: A patch to constify gcc.c (Really, summarizing remaining warnings)
- From: Zack Weinberg <zack at rabi dot columbia dot edu>
- Date: Wed, 10 Mar 1999 23:10:21 -0500
- cc: egcs-patches at cygnus dot com
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
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.