More interesting problems than C99 initialisers

[Matthew Wilcox <willy@debian.org>]

I'm seeing a lot of energy being expended converting the kernel from GNU
style initialisers to C99 style.  While proactively fixing the whims
of the gcc developers is laudable, there are more pressing problems.
gcc 3.2/3.3 seem to emit many more warnings -- I believe -Wall now
includes -Wsign-compare, but they don't document this in their changes
file.  Time spent fixing these additional warnings seems much more useful.

Use of the min/max macros also causes warnings in some cases.
See: http://gcc.gnu.org/ml/gcc/2002-11/msg00327.html and
http://gcc.gnu.org/ml/gcc/2002-11/msg00333.html

We can't compile the kernel with -std=gnu99 because our spinlock
initialisers are apparently a gnu89 extension that's removed from gnu99.

BTW, here's a patch that fixes gnu89 mode to not warn about min/max:

Index: gcc/c-decl.c
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/c-decl.c,v
retrieving revision 1.353
diff -u -r1.353 c-decl.c
--- gcc/c-decl.c        10 Nov 2002 16:24:24 -0000      1.353
+++ gcc/c-decl.c        18 Nov 2002 22:03:49 -0000
@@ -3788,12 +3788,15 @@
   restrictp = !! (specbits & 1 << (int) RID_RESTRICT) + TYPE_RESTRICT (type);
   volatilep = !! (specbits & 1 << (int) RID_VOLATILE) + TYPE_VOLATILE (type);
   inlinep = !! (specbits & (1 << (int) RID_INLINE));
-  if (constp > 1 && ! flag_isoc99)
-    pedwarn ("duplicate `const'");
-  if (restrictp > 1 && ! flag_isoc99)
-    pedwarn ("duplicate `restrict'");
-  if (volatilep > 1 && ! flag_isoc99)
-    pedwarn ("duplicate `volatile'");
+  if (flag_iso && ! flag_isoc99)
+    {
+      if (constp > 1)
+       pedwarn ("duplicate `const'");
+      if (restrictp > 1)
+       pedwarn ("duplicate `restrict'");
+      if (volatilep > 1)
+       pedwarn ("duplicate `volatile'");
+    }
   if (! flag_gen_aux_info && (TYPE_QUALS (type)))
     type = TYPE_MAIN_VARIANT (type);
   type_quals = ((constp ? TYPE_QUAL_CONST : 0)

I certainly can't be bothered to go through their submissions procedure
for a patch which will probably be rejected.  Maybe vendors will pick
up this patch.  Who knows.

-- 
Revolutions do not require corporate support.