Re: Cleaning up compile-time warnings

[Michal Jaegermann <michal harddata com>]

On Tue, Jun 05, 2007 at 09:19:30PM -0500, Luis Rodrigo Gallardo Cruz wrote:
> As you probably know, there are a number of weird bugs in sawfish that
> only come up in amd64 ...

Maybe; but I am running sawfish on x86_64, a.k.a. amd64, and also
on Fedora 7 installation and the current Fedora rawhide and somehow
I am not troubled by those.  It is quite possible that my usage does
not trigger these bugs.  I really do not know.  OTOH sources which
I was using came from CVS/SVN so they diverged quite a bit from
what was a "release" a long time ago.  Still sawfish has also quite
long history on Alpha starting with early releases.

> Since I don't really have a clue about where to search for them, I
> decided to start by cleaning up the many
>  "pointer targets in passing argument n of * differ in signedness"
> warnings one get when compiling, on the theory that those warnings may
> be real bugs.

The answer here is "very much depends".

> At first glance, they seem to be in two main categories:
> 
> * Those caused by the rep_STR macro, which ends up resolving to a
> unsigned char *, which is then fed to functions that
> take a char *.

There are two possible interpretations here.  One is that in C
standard 'char' is deliberatly underspecified type so a function
taking char should be able to accept both signed and unsigned
variations and gcc is too noisy here.  The other one is that an
interpretation of 'char' is compiler dependent so if you specify
signedness you should not play with it loose and gcc has a
legitimate beef.  Take your pick.

> I've decided to assume these cause no bugs since both
> the x86 and the amd64 ABIs call for signed chars as default, so any
> problems with this would be showing up in x86 too.

Does not necessary follow.  A signed expansion to int, which happens
automatically in various contexts, and used later as an unsigned
long or address, may end up with a high bit set on 32-bits and 0 in
an upper half on 64 bits.  Usually this is not an issue but
depending on how results are used it might be.  Or something else
similar but normally far from obvious may hit you.

> * Those caused by calls to Xlib. These are the ones I'm going to try
> to clean up.

X is infamous for an abuse of pointers as "universal storage
containers for various integer types" with a possibility to create
problems like above.  Have fun here.

> So, questions: Do these assumptions seem real enough?

General cleanups help very much to find bugs by reducing a noise.
Keep in mind that just adding casts to shut-up a compiler does not
fall into that category and it may even mask bugs.

If you have well-defined, repeateable, bugs then hunting for
those may be more effective but if you would have real code cleanups
that would be worthwhile.

   Michal