🚀 go-pugleaf

I just finished building X11 R5 pl 12 on a second machine (Sun-4/75GS, 4.1.2)
this time using gcc 2.2.2 (I'd first built it on my home 4/60GX using gcc 2.1).

The single solitary glitch came when compiling "twm" (in mit/clients/twm):

gcc -fpcc-struct-return -c -O2    -I../../.      gram.c
In file included from twm.h:297, from gram.c:44:
/usr/gnu/lib/gcc-lib/sparc-sun-sunos4.1/2.2.2/include/stdlib.h:29: conflicting t
ypes for `malloc'
gram.c:1: previous declaration of `malloc'
/usr/gnu/lib/gcc-lib/sparc-sun-sunos4.1/2.2.2/include/stdlib.h:33: conflicting t
ypes for `realloc'
gram.c:1: previous declaration of `realloc'
*** Error code 1

Further investigation shows:

- gram.c is created by doing "yacc -d gram.y".  This creates a gram.c with
  this at the very beginning:

extern char *malloc(), *realloc();

# line 42 "gram.y"
#include <stdio.h>
#include <ctype.h>
#include "twm.h"
...

- gcc's "finxincludes" takes <stdlib.h> and modifies it to change the return
  value of "malloc" and "realloc" (among other things) to be "void *" instead
  of "char *", as of gcc 2.2

- Thus, when "gram.c" included "twm.h", which contains

...
#include <X11/Xosdefs.h>
#ifndef X_NOT_STDC_ENV
#include <stdlib.h>
#else
extern char *malloc(), *calloc(), *realloc(), *getenv();
extern void free();
...

  then <stdlib.h> got included because I don't use "-nostdhdrs" or anything,
  so gcc complained about the re-declarations.

This made me think:

- Am I the first person to try a full build of X11 R5 since 2.2/2.2.1/2.2.2
  came out?  (-:  "fixincludes" didn't change those "stdlib.h" return values
  until 5 days after 2.1 came out (see the ChangeLog file).

- What's the correct solution to this problem?  You probably can't convince
  the X consortium to change from using "yacc", and the code in "twm.h" seems
  to think that if you're using a STDC environment - which I presume gcc 2.2.2
  is meant to provide, right? - then it's perfectly OK for it to include
  <stdlib.h>, and an ANSI-ized one at that.  Yet twm.h is being included in a
  file that was produced by a non-ANSI "yacc" which includes non-ANSI
  declarations.  So, what to do?

  I think that "yacc -d gram.y" will always create "gram.c" with these un-ANSI
  "extern char *malloc(), *realloc();" declarations if the "yacc" used is not
  ANSI-compatible.  I got around the problem by manually re-generating both
  gram.c/gram.h with Sun's C 1.1 "ayacc"; it didn't create the offending lines
  like plain "yacc" does:

# line 42 "gram.y"
#include <stdio.h>
#include <ctype.h>
#include "twm.h"
#include "menus.h"

  I presume "bison" might also fix this problem as well.

- libg++ 2.1 seems to prefer its own stdlib.h:

-r--r--r--  1 root         1376 Oct 23  1991 /usr/include/stdlib.h
-rw-r--r--  1 root         1379 Jun 18 21:02 /usr/local/src/gnu/lib/gcc-lib/sparc-sun-sunos4.1/2.2.2/include/stdlib.h
-rw-rw----  1 39           1831 Jan 17 15:04 /usr/local/src/gnu/src/libg++-2.1/libg++/g++-include/stdlib.h

  Is there some reason why gcc uses a fixincludes'd version of <stdlib.h>
  instead of this version that comes with libg++?  If you install libg++ 2.1
  then its version of <stdlib.h> will get put in ...lib/g++-include/stdlib.h
  and used by g++ from then on, whereas if you don't install libg++ then g++
  uses the old system version ...

Somewhat related/unrelated gcc 2.2.2 question:

Have the default warnings in gcc changed between 2.1 and 2.2.2?  For example,
when I compiled X originally with 2.1, I got no warnings produced by any of
the files in .../mit/clients/twm:

making all in ./clients/twm...
gcc -fpcc-struct-return -c -O2    -I../../.      gram.c
gcc -fpcc-struct-return -c -O2    -I../../.      lex.c
...
gcc -fpcc-struct-return -c -O2    -I../../.      menus.c
gcc -fpcc-struct-return -c -O2    -I../../.      events.c
...
rm -f twm

Compiling with 2.2.2 yields lots of complaints:

making all in ./clients/twm...
...
gcc -fpcc-struct-return -c -O2    -I../../.      menus.c
menus.c:57: warning: initialization of `RootFunction' makes integer from pointer
 without a cast
menus.c: In function `InitMenus':
menus.c:116: warning: assignment makes integer from pointer without a cast
menus.c:120: warning: assignment makes integer from pointer without a cast
menus.c:121: warning: assignment makes integer from pointer without a cast
menus.c: In function `ExecuteFunction':
menus.c:1344: warning: assignment makes integer from pointer without a cast
menus.c:1468: warning: comparison between pointer and integer
menus.c: In function `DeIconify':
menus.c:2430: warning: comparison between pointer and integer
menus.c: In function `Iconify':
menus.c:2510: warning: comparison between pointer and integer

Do I take it that the default warnings got "tighter" between 2.1 and 2.2.2?
Just out of curiosity ... (and sorry for the verbosity (-: )