Re: [gtk-list] Re: compiling gtk+ on solaris

[Drazen Kacar <dave srce hr>]

Erik Mouw wrote:
> On Thu, 23 Dec 1999 14:09:31 +0100, Drazen Kacar wrote:
> > Erik Mouw wrote:
> >> Which is the same on a SuSE Linux 6.1 and a Debian 2.1 box. Does this mean
> >> that SGI and XFree86 add ANSI compliant prototypes to each function, or
> >> that Sun *removes* the prototypes?
> > 
> > I think Sun didn't touch them. I suppose other vendors added the missing
> > declarations, which is what one would expect for OS's where gcc is the
> > only compiler, at least. I didn't check the original X distribution, so I
> > might be wrong.
> 
> I just downloaded Xlib.h from the X11R6.3 distribution and it *doesn't*
> contain proper prototypes.

Then the same is probably true for X11R6.4. That's what I have on Solaris.

> This is *exactly* as they are declared in the X11R6.3 source. SGI IRIX 6.3
> and Linux declare them as:
> 
>   extern int XActivateScreenSaver(
>   #if NeedFunctionPrototypes
>       Display*            /* display */
>   #endif
>   );
> 
>   extern int XAddHost(
>   #if NeedFunctionPrototypes
>       Display*            /* display */,
>       XHostAddress*       /* host */
>   #endif
>   );
> 
> > Man pages also doesn't have more information about the type returned. I think
> > these should be void, but I'm not 100% sure.
> 
> I think XFree86 and SGI looked at the source to find out the proper return
> type.

Could be. OTOH, K&R C says that undeclared functions return int, so it's
safe to put it even without looking at the source.

> >> > Although it's annoying when gcc compiles C program, it's not a real
> >> > problem. But g++ (new versions) will refuse to compile those files.
> >> 
> >> And for valid reasons. The gcc team worked towards a *correct* C/C++
> >> compiler implementation. Sometimes this means that previously assumed
> >> correct C constructions fail with gcc 2.95.2, but my experience is that
> >> all "sane coded" programs pass gcc 2.95.2 with no or little changes.
> > 
> > Sun's C compiler doesn't warn in this case. I haven't tried with their
> > C++ compiler, though.
> 
> Gcc and SGI's C compiler both warn in this case (and for good reasons), so
> that's the reason why XFree86 and SGI changed the include files. So it
> turns out to be a "bug" in the Sun C compiler.

I'd agree if there wasn't something strange going on. Sun's cc has -Xc
option which:

          c (conformance)
	       Strictly conformant ANSI/ISO C, without K&R C compati-
	       bility extensions.  The compiler will issue errors and
	       warnings for programs that use non-ANSI/ISO C con-
	       structs.

I tried to compile Xlib program on which I'm currently working with cc -Xc,
but it didn't complain. Then I tried with lint. It complained about
undeclared exit() (I forgot to #include <stdlib.h>), but not about
X include files. Then I tried with Sun's CC. It printed an error
about undeclared exit() and refused to compile, but nothing about X stuff.
They all have their private include directories, but there are no X include
files there. I cannot explain this.

> >> I can't decide which is worse: Sun changing the include files or X/Open
> >> *not* adding proper prototypes.
> > 
> > Tough decision, I agree. :-)
> 
> Which is worse: X/Open not adding proper prototypes, or Sun not
> implementing a proper C compiler? :-)

Sun not adding proper prototypes. I'll have to find out why CC and lint
don't complain before concluding they didn't implement proper compilers
and filing a bug report.

-- 
 .-.   .-.    I don't work for my employer.
(_  \ /  _)
     |        dave@srce.hr
     |        dave@fly.srk.fer.hr