recent win32 build errors
hello! after seeing a rash of win32 build problems, i decided to look into what is going on. one problem i noticed in the emails was Configure.pl was being run twice. once by the user (as expected), and once by nmake. the reason is quiet cute: when Configure.pl is run, it copies platforms/win32.h to include/parrot/platform.h. Makefile.in has a rule that sets Configure.pl as a dependency to $(STICKY_FILES) ... and platform.h is a member of the $(STICKY_FINGERS) macro. well, Configure.pl's timestamp is newer than win32.h! therefore, nmake will quiet understandably run Configure.pl every time. Configure.pl should forciably touch any file it copies since that copies the file timestamps too. for my testing purpopses, i just removed the dependency in Makefile.in and nmake was happy. that brings me to the next problem: string.c. there are a slew of compile errors in this file, and it all is based on pointer math on void pointers. for example, STRING has a void* bufstart member, and various functions (like string_make) try to do pointer math with it. void pointers have no size; therefore, pointer math won't work. visual c++ enforces this, and i'm a little surprised that gcc doesn't. i guess it just treats it as a char*? everything else seems to compile fine. there are a few compiler warnings due to some functions not returning values (most notiably some files in the classes directory). i'll see about working up a patch tomorrow, but a few questions for the parrot code police. what is the best way to touch a file from inside of perl? also, what is the prefered way of handling the void pointers? casting to char*? some other typedef? change STRING::bufstart from a void* to a char*? ...etc... -lee berger [EMAIL PROTECTED]
Re: recent win32 build errors
On Mon, Dec 31, 2001 at 03:51:37AM -0500, Lee Berger wrote: that brings me to the next problem: string.c. there are a slew of compile errors in this file, and it all is based on pointer math on void pointers. for example, STRING has a void* bufstart member, and various functions (like string_make) try to do pointer math with it. void pointers have no size; therefore, pointer math won't work. visual c++ enforces this, and i'm a little surprised that gcc doesn't. i guess it just treats it as a char*? yes by default: cc -O2-I./include -DHAS_JIT -o string.o -c string.c cc -O2-I./include -DHAS_JIT -o encoding.o -c encoding.c but: cc -O2 -Wpointer-arith-I./include -DHAS_JIT -o string.o -c string.c string.c: In function `string_make': string.c:64: warning: pointer of type `void *' used in arithmetic string.c: In function `string_transcode': string.c:171: warning: pointer of type `void *' used in arithmetic string.c:173: warning: pointer of type `void *' used in arithmetic string.c:186: warning: pointer of type `void *' used in subtraction string.c:188: warning: pointer of type `void *' used in arithmetic string.c: In function `string_concat': string.c:229: warning: pointer of type `void *' used in arithmetic string.c: In function `string_substr': string.c:311: warning: pointer of type `void *' used in subtraction string.c:312: warning: pointer of type `void *' used in subtraction string.c:314: warning: pointer of type `void *' used in arithmetic string.c: In function `string_chopn': string.c:328: warning: pointer of type `void *' used in arithmetic string.c:336: warning: pointer of type `void *' used in subtraction string.c:338: warning: pointer of type `void *' used in arithmetic string.c: In function `string_compare': string.c:362: warning: pointer of type `void *' used in arithmetic string.c:364: warning: pointer of type `void *' used in arithmetic string.c: In function `string_to_int': string.c:423: warning: pointer of type `void *' used in arithmetic string.c: In function `string_to_num': string.c:461: warning: pointer of type `void *' used in arithmetic cc -O2 -Wpointer-arith-I./include -DHAS_JIT -o encoding.o -c encoding.c Could I suggest that for gcc we turn on maximal bitchiness, /please/ -Wall, -W and everything even bitchier still that we can get away with. One needs to enforce such stricture early in the project, else it becomes impossible to retrofit it later. I know that turning on gcc bitchiness doesn't directly help anyone testing and committing code who is testing with any other compiler, but assuming that a reasonable proportion of people here (50%?) are using gcc it should cause any problems to be detected fairly early. I'll also volunteer to tidy up all the current code to as many warnings I can find (but not necessarily be the one correcting things hereafter), assuming that this idea is considered worthy. i'll see about working up a patch tomorrow, but a few questions for the parrot code police. what is the best way to touch a file from inside of perl? also, what is the prefered way of handling the void pointers? casting to char*? some other typedef? change STRING::bufstart from a void* to a char*? ...etc... utime is probably the best way to touch a file from inside perl. Nicholas Clark
Re: recent win32 build errors
On Mon, Dec 31, 2001 at 12:51:32PM +, Nicholas Clark wrote: Could I suggest that for gcc we turn on maximal bitchiness, /please/ -Wall, -W and everything even bitchier still that we can get away with. You are, of course, correct. gcc is a lot laxer than many other compilers, so we want to get away with as little as possible. -Wall should be default for gcc. (And please remember that not every compiler supports -Wall, so make it gcc specific!) I'll also volunteer to tidy up all the current code to as many warnings I can find (but not necessarily be the one correcting things hereafter), assuming that this idea is considered worthy. That would be absolutely wonderful. -- Complete the following sentence: People *ought* to weigh bricks, cats and cinnamon in the same units because... - Ian Johnston
Re: recent win32 build errors
At 13:36 on 12/31/2001 GMT, Simon Cozens [EMAIL PROTECTED] wrote: You are, of course, correct. gcc is a lot laxer than many other compilers, so we want to get away with as little as possible. -Wall should be default for gcc. (And please remember that not every compiler supports -Wall, so make it gcc specific!) I already submitted a patch for this, and it has been applied. I also added a pedantic option to Configure.pl. That kicks it up anohter notch. (bam.) --Josh
Re: recent win32 build errors
At 01:36 PM 12/31/2001 +, Simon Cozens wrote: On Mon, Dec 31, 2001 at 12:51:32PM +, Nicholas Clark wrote: Could I suggest that for gcc we turn on maximal bitchiness, /please/ -Wall, -W and everything even bitchier still that we can get away with. You are, of course, correct. gcc is a lot laxer than many other compilers, so we want to get away with as little as possible. -Wall should be default for gcc. (And please remember that not every compiler supports -Wall, so make it gcc specific!) I committed a patch yesterday that forces -Wall for gcc builds. If that's not cranky enough, give me a list of more gcc switches and I'll add 'em into the list. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: recent win32 build errors
At 03:21 PM 12/31/2001 +, Simon Cozens wrote: On Mon, Dec 31, 2001 at 09:50:08AM -0500, Dan Sugalski wrote: I committed a patch yesterday that forces -Wall for gcc builds. If that's not cranky enough, give me a list of more gcc switches and I'll add 'em into the list. I'd be very tempted to throw -Werror on there as well, just to force the issue a little. This is jogging my memory some. Jarkko passed on his gcc switch list from hell to me a while back--let me dig it out and add them in. This is *not* going to be pretty for the next few days... Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: recent win32 build errors
On Mon, Dec 31, 2001 at 03:21:38PM +, Simon Cozens wrote: On Mon, Dec 31, 2001 at 09:50:08AM -0500, Dan Sugalski wrote: I committed a patch yesterday that forces -Wall for gcc builds. If that's not cranky enough, give me a list of more gcc switches and I'll add 'em into the list. I'd be very tempted to throw -Werror on there as well, just to force the issue a little. This is *not* a good idea. The problem is that not all warnings are your own fault :) I have seen a lot of examples where a missing prototype or redefinition in OS headers results in a compile-time warning, and -Werror would definately be the wrong thing then. You should use -Werror only if you're afraid of not seeing stderr messages from gcc, or want gcc to stop compiling at the first error to avoid the usual cascade of weird, seemingly incorrect errors. :) -Wall good, -Werror bad. -pedantic could clash with any gcc-specific code such as the calculated-goto. -- Thomas Wouters [EMAIL PROTECTED] Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
Re: recent win32 build errors
On Mon, Dec 31, 2001 at 10:02:19AM -0500, Josh Wilmes wrote:
At 13:36 on 12/31/2001 GMT, Simon Cozens [EMAIL PROTECTED] wrote:
You are, of course, correct. gcc is a lot laxer than many other compilers,
so we want to get away with as little as possible. -Wall should be default
for gcc. (And please remember that not every compiler supports -Wall, so
make it gcc specific!)
I already submitted a patch for this, and it has been applied. I also
added a pedantic option to Configure.pl. That kicks it up anohter
notch. (bam.)
The problem is that Configure.pl is deciding that it's gcc based on
$Config{ccname} eq gcc. $Config{ccname} doesn't exist in perl5.005_03
(or presumably earlier). That's the undefined warning on line 183 below/
So, there's two or three chances to miss getting gcc. With Configure.pl of 5
minutes ago, on this BSD I get:
nick@thinking-cap [parrot]$ ./Configure.pl
Parrot Version 0.0.3 Configure
Copyright (C) 2001-2002 Yet Another Society
Since you're running this script, you obviously have
Perl 5--I'll be pulling some defaults from its configuration.
Checking the MANIFEST to make sure you have a complete Parrot kit...
Okay, we found everything. Next you'll need to answer
a few questions about your system. Rules are the same
as Perl 5's Configure--defaults are in square brackets,
and you can hit enter to accept them.
Use of uninitialized value at ./Configure.pl line 183.
What C compiler do you want to use? [cc] gcc
How about your linker? [cc] gcc
What flags would you like passed to your C compiler? []
Which libraries would you like your C compiler to include? [-lm -lc -lcrypt]
How big would you like integers to be? [long]
And your floats? [double]
What is your native opcode type? [long]
Probing Perl 5's configuration to determine which headers you have (this could
take a while on slow machines)...
Determining C data type sizes by compiling and running a small C program (this
could take a while):
Building ./test.c from test_c.in...
Figuring out the formats to pass to pack() for the various Parrot internal
types...
Building a preliminary version of include/parrot/config.h, your Makefiles, and
other files:
Building include/parrot/config.hfrom config_h.in...
Building ./Makefile from Makefile.in...
Building ./classes/Makefile from classes/Makefile.in...
Building ./languages/Makefile from languages/Makefile.in...
Building ./languages/jako/Makefile from languages/jako/Makefile.in...
Building ./languages/miniperl/Makefile from languages/miniperl/Makefile.in...
Building ./languages/scheme/Makefilefrom languages/scheme/Makefile.in...
Building Parrot/Types.pmfrom Types_pm.in...
Building Parrot/Config.pm from Config_pm.in...
Checking some things by compiling and running another small C program (this
could take a while):
Building ./testparrotsizes.cfrom testparrotsizes_c.in...
Updating include/parrot/config.h:
Building include/parrot/config.hfrom config_h.in...
Okay, we're done!
You can now use `make' (or your platform's equivalent to `make') to build your
Parrot. After that, you can use `make test' to run the test suite.
Happy Hacking,
The Parrot Team
nick@thinking-cap [parrot]$ make
/usr/bin/perl vtable_h.pl
/usr/bin/perl make_vtable_ops.pl vtable.ops
/usr/bin/perl ops2c.pl C core.ops vtable.ops
/usr/bin/perl ops2c.pl CPrederef core.ops vtable.ops
/usr/bin/perl ops2pm.pl core.ops vtable.ops
/usr/bin/perl -MFile::Copy=cp -e 'cp q|Parrot/Jit/i386-bsd.pm|, q|Parrot/Jit.pm|'
/usr/bin/perl jit2h.pl i386 include/parrot/jit_struct.h
gcc -I./include -DHAS_JIT -o test_main.o -c test_main.c
gcc -I./include -DHAS_JIT -o global_setup.o -c global_setup.c
^C
nick@thinking-cap [130]$ gcc --version
2.95.2
Note that I've even told Configure that I'm using gcc, not cc, and it still
doesn't do the GCC stuff.
Shall I submit a patch that makes Configure.pl check the the C compiler works
and if it's gcc (by compiling a test program that looks for gcc's version
macros, rather than trying to pass the output of ${cc} --version)
And the if it's gcc in the tin (whatever the label says) do Dan's
$c{cc_warn} = -Wall -ansi -pedantic -Wtraditional -Wstrict-prototypes
-Wmissing-prototypes -Winline -Wredundant-decls -Wall -Wshadow -Wpointer-arith
-Wcast-qual -Wcast-align -Wwrite-strings -Wconversion -Waggregate-return -Winline;
[hmm it seems that -ansi enables -trigraphs, and -Wall enables -Wtrigraphs,
so that's good (in that I feel we want to know about them if anyone uses them)]
For information, here's what /cc/ stuff I have in %Config:
nick@thinking-cap [parrot]$ /usr/bin/perl -MConfig -lwe 'foreach (keys %Config){print
if /cc/}'
cc
ccflags
Mcc
byacc
cccdlflags
ccdlflags
ccsymbols
cppccsymbols
d_access
d_locconv
gccversion
nick@thinking-cap [parrot]$ /usr/bin/perl -v
This is perl, version
Re: recent win32 build errors
At 03:55 PM 12/31/2001 +, Nicholas Clark wrote:
Shall I submit a patch that makes Configure.pl check the the C compiler works
and if it's gcc (by compiling a test program that looks for gcc's version
macros, rather than trying to pass the output of ${cc} --version)
And the if it's gcc in the tin (whatever the label says) do Dan's
$c{cc_warn} = -Wall -ansi -pedantic -Wtraditional
-Wstrict-prototypes -Wmissing-prototypes -Winline -Wredundant-decls -Wall
-Wshadow -Wpointer-arith -Wcast-qual -Wcast-align -Wwrite-strings
-Wconversion -Waggregate-return -Winline;
Yes, please. This'll catch the systems based on GCC (like the Mac OS X
compiler) that don't look like that in Config.pm
Dan
--it's like this---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: recent win32 build errors
On Mon, Dec 31, 2001 at 11:03:38AM -0500, Dan Sugalski wrote: Yes, please. This'll catch the systems based on GCC (like the Mac OS X compiler) that don't look like that in Config.pm I was just about to complain that my perl was built with cc, which is a symlink to gcc. -- Resist the urge to start typing; thinking is a worthwhile alternative. -- Kernighan and Pike
Re: recent win32 build errors
At 04:10 PM 12/31/2001 +, Simon Cozens wrote: On Mon, Dec 31, 2001 at 11:03:38AM -0500, Dan Sugalski wrote: Yes, please. This'll catch the systems based on GCC (like the Mac OS X compiler) that don't look like that in Config.pm I was just about to complain that my perl was built with cc, which is a symlink to gcc. I ended up hacking an entry into Config.pm for me, as my linux machine's running 5.005_03. If you want fun, try on CygWin--all the generated files get extra ^Ms on their line endings, and GCC doesn't like that in macros... Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: recent win32 build errors
At 04:39 PM 12/31/2001 +0100, Thomas Wouters wrote: On Mon, Dec 31, 2001 at 03:21:38PM +, Simon Cozens wrote: On Mon, Dec 31, 2001 at 09:50:08AM -0500, Dan Sugalski wrote: I committed a patch yesterday that forces -Wall for gcc builds. If that's not cranky enough, give me a list of more gcc switches and I'll add 'em into the list. I'd be very tempted to throw -Werror on there as well, just to force the issue a little. This is *not* a good idea. The problem is that not all warnings are your own fault :) I have seen a lot of examples where a missing prototype or redefinition in OS headers results in a compile-time warning, and -Werror would definately be the wrong thing then. You should use -Werror only if you're afraid of not seeing stderr messages from gcc, or want gcc to stop compiling at the first error to avoid the usual cascade of weird, seemingly incorrect errors. :) We'll burn those bridges when we get to them. Right now I want to clean up all the errors our code throws because of these. -Wall good, -Werror bad. -pedantic could clash with any gcc-specific code such as the calculated-goto. -pedantic can go in that case, but since we're not there quite yet it's OK. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
[PATCH] Re: recent win32 build errors
On Mon, Dec 31, 2001 at 11:03:38AM -0500, Dan Sugalski wrote:
Yes, please. This'll catch the systems based on GCC (like the Mac OS X
compiler) that don't look like that in Config.pm
On Mon, Dec 31, 2001 at 10:39:54AM -0500, Dan Sugalski wrote:
Folks,
I've just made a few minor changes to configure.pl regarding the switches
for gcc. Now instead of -Wall being the defaults, it's:
-Wall -ansi -pedantic -Wtraditional -Wstrict-prototypes
-Wmissing-prototypes -Winline -Wredundant-decls -Wall -Wshadow
-Wpointer-arith -Wcast-qual -Wcast-align -Wwrite-strings -Wconversion
-Waggregate-return -Winline
And yes, I see that -Wall's in there twice. (You never notice until after
commit)
I added -W -Wsign-compare to it, and
-Wformat-nonliteral -Wformat-security -Wpacked -Wpadded -Wdisabled-optimization
for gcc 3.0
We may not want all these.
Patch appended, new gcc test program attached.
Hopefully this is a the right style of doing things.
Nicholas Clark
--- Configure.pl.orig Mon Dec 31 15:32:56 2001
+++ Configure.plMon Dec 31 18:18:26 2001
@@ -178,12 +178,6 @@
$c{PQ} = ';
}
-# If using gcc, crank up its warnings as much as possible and make it behave
-# ansi-ish.
-if ($Config{ccname} eq gcc) {
- $c{cc_warn} = -Wall -ansi -pedantic -Wtraditional -Wstrict-prototypes
-Wmissing-prototypes -Winline -Wredundant-decls -Wall -Wshadow -Wpointer-arith
-Wcast-qual -Wcast-align -Wwrite-strings -Wconversion -Waggregate-return -Winline;
-}
-
# Add the -DHAS_JIT if we're jitcapable
if ($jitcapable) {
$c{cc_hasjit} = -DHAS_JIT;
@@ -225,6 +219,101 @@
prompt(And your floats?, 'nv');
prompt(What is your native opcode type?, 'opcode_t');
+print END;
+
+Determining if your C compiler is actually gcc (this could take a while):
+
+END
+
+{
+my %gnuc;
+
+compiletestc(test_gnuc);
+%gnuc=eval(runtestc()) or die Can't run the test program: $!;
+unlink(test_siz$c{exe}, test$c{o});
+
+unless (exists $gnuc{__GNUC__}) {
+print 'END';
+
+The test program didn't give the expected result - assuming your compiler is
+not gcc.
+
+END
+
+} else {
+ my $major = $gnuc{__GNUC__};
+my $minor = $gnuc{__GNUC_MINOR__};
+unless (defined $major) {
+print 'END';
+
+Your C compiler is not gcc.
+
+END
+} else {
+ print Your C compiler reports itself as gcc, major version $major;
+print , minor version $minor if defined $minor;
+ }
+print .\n\n;
+if ($major =~ tr/0-9//c) {
+print major version '$major' is not an integer,
+ - I don't think that this is gcc.;
+undef $major; # Don't use it
+}
+if (defined $minor and $minor =~ tr/0-9//c) {
+print minor version '$minor' is not an integer.;
+undef $minor; # Don't use it
+}
+if (defined $major) {
+$c{gccversion} = $major;
+$c{gccversion} .= .$minor if defined $minor;
+}
+}
+
+}
+
+if ($c{gccversion}) {
+# If using gcc, crank up its warnings as much as possible and make it
+# behave ansi-ish.
+# Here's an attempt at a list of nasty things we can use for a given
+# version of gcc. The earliest documentation I currently have access to is
+# for 2.95, so I don't know what version everything came in at. If it turns
+# out that you're using 2.7.2 and -Wfoo isn't recognised there, move it up
+# into the next version becone (2.8)
+
+
+my @opt_and_vers =
+(0 = -Wall -ansi -pedantic -Wtraditional -Wstrict-prototypes
+-Wmissing-prototypes -Winline -Wredundant-decls -Wshadow -Wpointer-arith -Wcast-qual
+-Wcast-align -Wwrite-strings -Wconversion -Waggregate-return -Winline -W
+-Wsign-compare,
+# others; ones we might like marked with ?
+# ? -Wundef for undefined idenfiers in #if
+# ? -Wbad-function-cast
+# Warn whenever a function call is cast to a non-matching type
+# ? -Wmissing-declarations
+# Warn if a global function is defined without a previous declaration
+# -Wmissing-noreturn
+# ? -Wredundant-decls
+#Warn if anything is declared more than once in the same scope,
+# ? -Wnested-externs
+#Warn if an `extern' declaration is encountered within an function.
+# -Wlong-long
+# Ha. this is the default! with -pedantic.
+# -Wno-long-long for the nicest bit of C99
+ 2.7 = ,
+ 2.8 = ,
+ 2.95 = ,
+ 3.0 = -Wformat-nonliteral -Wformat-security -Wpacked -Wpadded
+-Wdisabled-optimization,
+# -Wsequence-point is part of -Wall
+# -Wfloat-equal may not be what we want
+# We shouldn't be using __packed__, but I doubt -Wpacked will harm us
+# -Wpadded may prove interesting, or even noisy.
+# -Wunreachable-code might be useful in a non debugging version
+);
+while (my ($vers, $opt) = splice
Re: [PATCH] Re: recent win32 build errors
At 06:23 PM 12/31/2001 +, Nicholas Clark wrote: Patch appended, new gcc test program attached. Hopefully this is a the right style of doing things. It's good enough for now. I'm testing it now--when it's done I'll commit this. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: recent win32 build errors
Attached is a small patch to Configure.pl that touches platform.h and platform.c so that Configure.pl isn't run a second time when you do a make. This doesn't fix Win32's build problems but it makes it less annoying trying to figure out the cause of them. Jason. - Original Message - From: Lee Berger [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, December 31, 2001 12:51 AM Subject: recent win32 build errors hello! after seeing a rash of win32 build problems, i decided to look into what is going on. one problem i noticed in the emails was Configure.pl was being run twice. once by the user (as expected), and once by nmake. the reason is quiet cute: when Configure.pl is run, it copies platforms/win32.h to include/parrot/platform.h. Makefile.in has a rule that sets Configure.pl as a dependency to $(STICKY_FILES) ... and platform.h is a member of the $(STICKY_FINGERS) macro. well, Configure.pl's timestamp is newer than win32.h! therefore, nmake will quiet understandably run Configure.pl every time. Configure.pl should forciably touch any file it copies since that copies the file timestamps too. for my testing purpopses, i just removed the dependency in Makefile.in and nmake was happy. that brings me to the next problem: string.c. there are a slew of compile errors in this file, and it all is based on pointer math on void pointers. for example, STRING has a void* bufstart member, and various functions (like string_make) try to do pointer math with it. void pointers have no size; therefore, pointer math won't work. visual c++ enforces this, and i'm a little surprised that gcc doesn't. i guess it just treats it as a char*? everything else seems to compile fine. there are a few compiler warnings due to some functions not returning values (most notiably some files in the classes directory). i'll see about working up a patch tomorrow, but a few questions for the parrot code police. what is the best way to touch a file from inside of perl? also, what is the prefered way of handling the void pointers? casting to char*? some other typedef? change STRING::bufstart from a void* to a char*? ...etc... -lee berger [EMAIL PROTECTED] utime.patch Description: Binary data
Re: recent win32 build errors
At 12:06 PM 12/31/2001 -0800, Jason Diamond wrote: Attached is a small patch to Configure.pl that touches platform.h and platform.c so that Configure.pl isn't run a second time when you do a make. This doesn't fix Win32's build problems but it makes it less annoying trying to figure out the cause of them. Applied, thanks. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: recent win32 build errors
On Mon, Dec 31, 2001 at 11:17:38AM -0500, Dan Sugalski wrote: [ Me: Don't use -Werror! ] We'll burn those bridges when we get to them. Right now I want to clean up all the errors our code throws because of these. Of course, as long as it appears in the development code, it's fine. It's not a good idea for 'real' releases, is what I meant to say. -- Thomas Wouters [EMAIL PROTECTED] Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
Re: recent win32 build errors
Dan Sugalski [EMAIL PROTECTED] writes: This is jogging my memory some. Jarkko passed on his gcc switch list from hell to me a while back--let me dig it out and add them in. This is *not* going to be pretty for the next few days... Here are some notes on what I've managed to live with: ## Warnings to use with gcc. Default to including all of the generally ## useful warnings unless there's something that makes them unsuitable. In ## particular, the following warnings are *not* included: ## ##-ansi Requires messing with feature test macros. ##-Wconversion Too much unsigned to signed noise. ##-Wredundant-decls Too much noise from system headers. ##-Wtraditional We assume ANSI C, so these aren't interesting. ##-Wundef Too much noise from system macros. ## ## Some may be worth looking at again once a released version of gcc doesn't ## warn on system headers. The warnings below are in the same order as ## they're listed in the gcc manual. We suppress warnings for long long ## because of lib/snprintf.c; all uses of long long should be hidden behind ## #ifdef HAVE_LONG_LONG. WARNINGS= -pedantic -Wall -W -Wshadow -Wpointer-arith \ -Wbad-function-cast -Wcast-qual -Wcast-align \ -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes \ -Wnested-externs -Wno-long-long The comment is a little dated, as I believe gcc 3.0 no longer warns on system headers, so -Wredundant-decls possibly could get pulled back in. -Wundef is a style thing. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
