bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: warning options


From: Bruno Haible
Subject: Re: warning options
Date: Mon, 28 Nov 2011 01:13:34 +0100
User-agent: KMail/1.13.6 (Linux/2.6.37.6-0.5-desktop; KDE/4.6.0; x86_64; ; )

Hi Paul,

> > "gcc -Wall" produces a warning for
> > 
> >   int f () { return 0; }
> >   int main (void) { return f (1); }
> 
> That's weird.  It doesn't produce a warning for me, for either
> GCC 4.6.1 (bundled with Fedora 15) or GCC 4.6.2 (which I built):
> 
> $ cat t.c
> int f () { return 0; }
> int main (void) { return f (1); }
> $ gcc -Wall t.c
> $ 

gcc 3.1 to 4.6.1, all built from source: No warning.

/usr/bin/gcc on openSuSE 11.4: a warning.
  gcc version 4.5.1 20101208 [gcc-4_5-branch revision 167585] (SUSE Linux)
foo.c: In function 'main':
foo.c:2:1: warning: call to function 'f' without a real prototype
foo.c:1:5: note: 'f' was declared here

Why does this warning only appear on openSuSE 11.4 ?? This warning
is more useful than -Wstrict-prototypes and -Wmissing-prototypes.

> > the 'main' function is better declared as () not (void) - since crt0.o 
> > calls it
> > with two arguments.
> 
> I don't quite follow that argument.  ...
> The worry is about what happens on platforms where it's
> not OK to call a function with extra arguments.
> On such platforms, the system presumably links differently
> depending on which form of 'main' the program defines.

How could it do that? The name mangling of the symbol 'main' is the same,
regardless of whether it's defined to take 0 or 2 arguments. (We're in C here,
not in C++.)

Instead, I think, on such platforms the system must call main as if it
was defined with varargs.

> > We want to minimize the
> > differences to the original glibc code.
> 
> Sure, but those macros defns aren't needed anywhere.  They're in glibc
> only because of gnulib.  If gnulib doesn't need them, they should be
> removed from both glibc and gnulib.

Good point. I'm applying these cleanups then. To be pushed into glibc the
next time you make a sync.


2011-11-27  Bruno Haible  <address@hidden>

        Remove unused macros from !_LIBC code in glibc-borrowed files.
        * lib/fnmatch.c (STRCOLL): Remove macro.
        * lib/fnmatch_loop.c (STRCOLL): Remove undef.
        * lib/glob.c (__stat, __readdir64): Remove macros.
        * lib/tempname.c (__open64, __xstat64): Remove macros.
        Suggested by Paul Eggert.

--- lib/fnmatch.c.orig  Mon Nov 28 01:06:22 2011
+++ lib/fnmatch.c       Mon Nov 28 01:02:27 2011
@@ -168,7 +168,6 @@
 #  endif
 # endif
 # define MEMCHR(S, C, N) memchr (S, C, N)
-# define STRCOLL(S1, S2) strcoll (S1, S2)
 # include "fnmatch_loop.c"
 
 
@@ -196,7 +195,6 @@
 #   endif
 #  endif
 #  define MEMCHR(S, C, N) wmemchr (S, C, N)
-#  define STRCOLL(S1, S2) wcscoll (S1, S2)
 #  define WIDE_CHAR_VERSION 1
 
 #  undef IS_CHAR_CLASS
--- lib/fnmatch_loop.c.orig     Mon Nov 28 01:06:22 2011
+++ lib/fnmatch_loop.c  Mon Nov 28 01:02:32 2011
@@ -1214,7 +1214,6 @@
 #undef END
 #undef MEMPCPY
 #undef MEMCHR
-#undef STRCOLL
 #undef STRLEN
 #undef STRCAT
 #undef L_
--- lib/glob.c.orig     Mon Nov 28 01:06:22 2011
+++ lib/glob.c  Mon Nov 28 01:05:18 2011
@@ -145,10 +145,8 @@
 # define __stat64(fname, buf)   stat (fname, buf)
 # define __fxstatat64(_, d, f, st, flag) fstatat (d, f, st, flag)
 # define struct_stat64          struct stat
-# define __stat(fname, buf)     stat (fname, buf)
 # define __alloca               alloca
 # define __readdir              readdir
-# define __readdir64            readdir64
 # define __glob_pattern_p       glob_pattern_p
 #endif /* _LIBC */
 
--- lib/tempname.c.orig Mon Nov 28 01:06:22 2011
+++ lib/tempname.c      Mon Nov 28 01:01:51 2011
@@ -67,9 +67,7 @@
 # define __gettimeofday gettimeofday
 # define __mkdir mkdir
 # define __open open
-# define __open64 open
 # define __lxstat64(version, file, buf) lstat (file, buf)
-# define __xstat64(version, file, buf) stat (file, buf)
 #endif
 
 #if ! (HAVE___SECURE_GETENV || _LIBC)

-- 
In memoriam George Moscone <http://en.wikipedia.org/wiki/George_Moscone>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]