[Mono-devel-list] Compiler Warnings..
Willibald.Krenn at gmx.at
Wed Dec 1 11:04:42 EST 2004
AFAIK mono is currently built using
Wall -Wunused -Wmissing-prototypes -Wmissing-declarations
-Wstrict-prototypes -Wmissing-prototypes -Wnested-externs
-Wpointer-arith -Wno-cast-qual -Wcast-align -Wwrite-strings
as arguments for gcc.
(At least this is partly correct, as haven't checked if these args are
I did a build in my private tree using the parameters above and logged
all warnings gcc emitted: This file is over 1400 lines. Sure, some of
the warnings are from code that isn't found in official mono and
probably lots of these warnings come from code that mono does not build
using the full warning parameter set from above, but that still leaves a
If I build my private tree with a set of
-g -O2 -DGC_LINUX_THREADS -D_GNU_SOURCE -D_REENTRANT -DUSE_COMPILER
_TLS (i.e. no warnings at all)
and after applying a patch to elimiate some int32<->pointer64 warnings,
I still get warnings in metadata/loader.c, reflection.c,
debug-mono-symfile.c, mono-debug-debugger.c and one in mini.c: warning:
#warning "fixme: add opcode emulation"
Question is: Why's mono even built using such a strict warning set, when
no-one seems to care? What warning level is considered to be 'standard'
To my first real patch: Attached to this mail you'll find some
modifications to eliminate gcc warnings on int32<->pointer64 casts. Note
that there are some interface changes too and I considere this version
as NOT ready for including in SV, but I need your comments in
correcting/developing this patch further.
I've introduced one additional global header file called intps.h: It's
sole purpose is to define an unsigned integer that is guaranteed to be
the same size as a pointer: uintps. (unsigned int pointer size)
/*definition of an unsigned int datatype that is always
#if SIZEOF_VOID_P == 8
typedef guint64 uintps;
typedef guint32 uintps;
Using this type as a basis, I've introduced casts wherever gcc (without
all warnings!) complained about integer size not matching pointer size..
But see attached diff.. Again, I do not consider it ready to commit,
cause I haven't run all tests and did not re-check if new warnings are
emitted when compiling with the strict warning set outlined above.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 22183 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20041201/1702a18c/attachment.bin
More information about the Mono-devel-list