Xref: utzoo gnu.gcc.help:33 comp.unix.xenix.sco:545
Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!shelby!snorkelwacker!bloom-beacon!eru!hagbard!sunic!compuram!pgd
From: pgd@bbt.se
Newsgroups: gnu.gcc.help,comp.unix.xenix.sco
Subject: Re: GCC with Xenix Include files
Message-ID: <1990Oct19.110130.19753@bbt.se>
Date: 19 Oct 90 11:01:30 GMT
References: <1990Oct14.161854@cs.yale.edu> <1990Oct16.081629.106@bbt.se> <8279@scolex.sco.COM>
Organization: .
Lines: 59

In article <8279@scolex.sco.COM> seanf (Sean Fagan) writes:
>
>In article <1990Oct16.081629.106@bbt.se> pgd@bbt.se writes:
>>If you update to 2.3.3 you will find that the include files, if
>>possible, are even more screwed up. 
>
>I think that the 2.3.1 DS update has this fix; the unix DS certainly
>does (and many, many of the header files are protected against multiple
>inclusion).
>
>>	#ifndef SIZE_T_DEFINED
>
>That, btw, is illegal, according to ANSI.  We use
>
>	#ifndef	_SIZE_T
>	typedef	unsigned int size_t;
>	#	define _SIZE_T
>	#endif	/* _SIZE_T */
>
>which is legal (namespace problems).
>
>>	#ifndef STDIO_INCLUDED
>
>For these, it's of the format
>
>	#ifndef	_STDIO_H
>	#	define	_STDIO_H
>	/* stdio.h stuff */
>	#endif	/* _STDIO_H */
>
>As I said, most of the header files in 3.2 have this already.

Ok, i had the 2.3.0 dev sys, and the 2.3.2 for the rest. Then I
upgraded to 2.3.2 with xnx155, and the result had name clashes in the
.h-files. The worst one was size_t, that is defined in
stdio.h, stdlib.h, string.h and time.h
I don't know the logic for that, but there result is that you cannot
include any if those files together. Maybe cc ignores equal multiple
typedefs of the same type?

There were a few other symbols also, but since i very soon fixed the
include files, i have forgot which ones, and as i don't have the
original ones on-line, i cannot say what i have made, and sco have made.

As for the names chosen, i just picked any that i felt were quite
unique, inspired by header files from another system (where this is
consistenly done). I don't feel it like my job to make xenix
ANSI-conformant.

All in all, i am happy that i could get xnx155, without guarantees,
even if it meant i had to do some hand hacking of the include files.
If SCO now (maybe)have fixed that problem, it means that all future
buyers will not have it.

Another point:
In sys/types.h you can find definitions for uchar_t, ulong_t and ushort.
Why this inconsistency. Why not uchar and ulong, or ushort_t?
This means that i constantly have to comment out/define typedefs in
programs that i try to compile on xenix.