On 11/20/11 16:25, Bruno Haible wrote: > "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 $ > the 'main' function is better declared as () not (void) - since crt0.o calls > it > with two arguments. I don't quite follow that argument. On platforms where the ABI is OK if a function is called with extra arguments, crt0.o can call main with a dozen arguments if it wants to. 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. But since the C standard doesn't say what to do when 'main' is defined without a prototype, the system need not do the right thing for that case. > 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.