Re: [Ipsec-tools-devel] -Werror isn't the right thing?

[<ato...@t-...>]

On Sun, 7 Aug 2005, VANHULLEBUS Yvan wrote:

> On Sun, Aug 07, 2005 at 01:08:55PM +0200, ato...@t-... wrote:
> > [signed and unsigned warnings...]
> > make[1]: Leaving directory `/home/fury/ipsec-tools-0.6'
> > make: *** [all] Fehler 2
>
> Those lines refers to a comparison betweew 'off', which is a size_t
> variable, and PFKEY_EXTLEN(xpl), which returns an uint16_t.
>
> As ANSI C requires size_t to be unsigned, I don't see where there is a
> problem here....
>
> But I just made a quick google search, and it looks like some old GCC
> / Glibc versions could consider size_t to be signed.

Unfortunately size_t *IS* unsigned (verified compiling a demo program
with -E):

...
# 1 "/usr/lib/gcc-lib/i486-suse-linux/3.3/include/stddef.h" 1 3 4
# 213 "/usr/lib/gcc-lib/i486-suse-linux/3.3/include/stddef.h" 3 4
typedef unsigned int size_t;
# 325 "/usr/lib/gcc-lib/i486-suse-linux/3.3/include/stddef.h" 3 4
typedef long int wchar_t;
...

Yvan, I don't understand why the compiler tells us that there's a
signedness problem here. The preprocessed line 234 looks like this:

        while (off < ((((struct sadb_ext *)(xpl))->sadb_ext_len) << 3)) {

... smells like a compiler bug in conjunction with the "(ushort) << 3" to
me.

> It may be the reason of your error messages, but if that's the
> problem, it is NOT an ipsec tools problem, it is a problem in your
> compilation platform !
>
>
> Can you check that, and at least tell us more informations about your
> gcc/libc version, your OS, the version of ipsec-tools you're using,
> etc... ?

Linux version is 2.6.11.11
gcc version 3.3 20030226 (prerelease) (SuSE Linux)
glibc version is 2.3.2
ipsec-tools version is 0.6.1rc1

> > Actually using
> >
> > for i in $(find -name Makefile); do sed  -e"s/Werror/Wall/g" <$i >$i-; cp
> > $i $i-old; cp $i- $i; done
> >
> > worked ... ;-).
>
> As Manu said, this is NOT a solution !!!

Yes, it is only a fix for a frustrated user ;-) - no patch. When
developing software I also like -Wall and -Werror.

The solution for the problem would be telling the users what
the minimal version numbers of the required software / libraries are.
Linux users are not always using 'bleeding edge' stuff - never touch a
running system (tm) ;-).
Using prerelease compilers/libs for a main-stream distribution is also a
bad idea in my point of view (aren't there any SuSE people on this list?
;-). It's a mistake many comercial distributions are doing today.

It would/should/could be the task of the configure script to find out
whether my system is using antique stuff - or broken compilers ;-). An
alternative would be a document, but documents are rarely read ...

Best regards,

 Stephan
 --
Stephan Fuhrmann