On Thu, Jan 03, 2008 at 11:14:45PM +0000, Wookey wrote:
> All these appear to be in wx headers, so maybe they are not really
> anything to do with therion, and all I should do is add
> -fno-strict-aliasing to the build to stop them appearing.

That's probably the simplest fix.

> But I'd like someone who groks C++ properly to tell me that's not just
> papering over cracks before doing so.

ISO C and C++ state in what cases the compiler can assume two pointers
to different types don't alias each other.  In other words, when a write
through one pointer won't affect data read by the other.  In recent
years, compilers have started to make more aggressive use of the
optimisations these rules allow, which causes problems for older code
which "works fine", but isn't actually valid C/C++.  So GCC helpfully
now produces warnings about code which it notices appears to violate
these aliasing rules.

So it's papering over the cracks in a sense in that the code isn't
valid C/C++, but you could think of it as the code being written in a
non-standardised dialect of C/C++ in which all pointers are assumed
to be able to alias.  This may lose some performance - whether it
actually makes much difference depends on the nature of the code.

> Doing this certainly removes all
> the noise and shows us that there is one genuine set of warnings:
> lxRender.cxx: In member function ???void lxRenderFile::RenderPDFHeader()???:
> lxRender.cxx:855: warning: format ???%u??? expects type ???unsigned int???, 
> but argument 3 has type ???size_t???
> lxRender.cxx: In member function ???void lxRenderFile::RenderPDFFooter()???:
> lxRender.cxx:929: warning: format ???%u??? expects type ???unsigned int???, 
> but argument 3 has type ???size_t???
> [...]
> 
> Does this just need some casts or should the format be changed?

One or the other - printf format "%u" expects "unsigned int", but is
being passed size_t which is 64 bits not 32 on 64 bit Linux.  If the
parameter could take any value, the format should be fixed.  If it will
always fit in a 32 bit value, casting to "unsigned int" is fine.

Cheers,
    Olly

Reply via email to