[openbeos] Re: getting serious about headers

On Sun, 10 Aug 2003 11:49:20 +0200 CEST "Axel Dörfler" 
<axeld@xxxxxxxxxxxxxxxx> wrote:
> "Andrew Bachmann" <shatty@xxxxxxxxxxxxx> wrote:
> > issue #1. posix unfriendly headers:
> 
> Could you give examples, which headers are unfriendly?
> I am working on the stdio.h issue, but anything else can be compatible 
> right now.

There is our socket.h right now.  Other things may be unfriendly but
I don't quite understand how to read the spec with respect to a few
things, namely: how to determine if a header can/should/must/can't/
shouldn't/musn't include another header.

> > issue #2. headers from gcc:
> 
> Those headers shouldn't be part of our repository as it is now (at 
> least for some headers), but are part of the GCC header path.

Yeah, this is the part of which I was talking about.

> In any way, it's not a legal issue to use those headers.

IANAL & lawsuits are expensive so I err on oversafe. :-)
 
> > issue #3: missing headers
> 
> Sure, there are a lot of missing headers. When me moved NewOS to our 
> repository, the header directories got messed up completely - the Posix 
> headers got mixed up with the kernel private headers.
> My usual habit was to let those headers staying in the private kernel 
> directory as long as they haven't been fixed/reviewed/rewritten for 
> BeOS/Posix compatibility.

Ah.. this seems to be the source of some of my troubles.

> We should not aim to support much more of Posix than BeOS did - only 
> those bits and pieces that made it hard porting applications to BeOS. 
> That would be definitely R2 material.

I agree with that.

> My proposal would be a bit simpler:
> 1. check what headers are missing from our posix/ tree, write that 
> down.
> 2. move/fix/rewrite existing Posix headers from private/kernel in there
> 3. add all other which are not delivered by GCC
> 
> Now, our primary source for 3. could be either the Posix spec provided 
> by the OpenGroup Base Specification (which would be my favourite), BeOS 
> headers (need to be checked against anyway), and *BSD headers.

Okay that sounds like less work to me. :-)  (This is why I ask the list :-) )

Here's a list so far.  These are headers or functions that are looked for by the
gcc 2.95.3 configuration procedure.  I've roughly ordered them from most
important to least, IMHO of course.

assert.h - posix, in kernel dir
ctype.h - posix, in kernel dir
sys/wait.h - posix, not in kernel dir, but in beos sys/wait.h
sys/resource.h - getrlimit(), setrlimit(), posix, in kernel dir
termcap.h - not posix, but in beos termcap.h
sys/file.h - not posix, but in beos sys/file.h, simply includes (posix) fcntl.h
sys/termio.h - not posix, but in beos sys/termio.h, simply includes (posix) 
termios.h
sys/fcntl.h - not posix, but in beos sys/fcntl.h, simply includes (posix) 
fcntl.h
string.h - ours has commented out strsignal() but gcc/Linux expects it in this 
header (not signal.h),

These are optional: (in roughly increasing order of optionality, IMHO)

libgen.h - posix XSI, defines basename(), dirname(), not in kernel dir or beos
search.h - posix XSI, defines insque(), remque(), not in kernel dir or beos
unistd.h - getpagesize(), posix declared LEGACY, not in kernel, commented out 
in beos
unistd.h - mkstemps(), not posix, not in kernel dir, not in beos, in *BSD
unistd.h - vfork(), posix XSI Obsolescent, but not in kernel dir or beos, in 
*BSD
signal.h - sigblock(), sigsetmask(), not posix, not in kernel, not in beos, in 
*BSD
stdio.h - fputs_unlocked(), not posix, in kernel glibc/libio subdir, not in 
beos, not in FreeBSD
stdio.h - sys_errlist, sys_nerr, not posix (use strerror instead), in kernel 
glibc/libio subdir, not in 
beos, in *BSD
stdlib.h - atoq() an obsolete name for atoll(), old posix/Linux (?)
stab.h - various symbols used by debuggers, not posix, not in kernel dir or 
beos, in *BSD
values.h - AIX version of limits.h afaik, not posix, not in kernel, not in 
beos, not in *BSD
argz.h - __argz_count & friends (?), not posix, not in kernel dir or beos or 
FreeBSD, in GNU 
Linux

These I have no idea about:

sys/ptem.h - not posix, not in kernel dir or beos or FreeBSD
sys/ttold.h - not posix, not in kernel dir or beos or FreeBSD
direct.h - not posix, not in kernel dir or beos or FreeBSD, some sort of DOS 
file header?
thread.h - not posix, presumably not the one in our kernel dir, not in beos or 
FreeBSD

Also missing but possibly troublesome(?), at least as far as resulting autoconf 
binaries running on 
R5:

sys/mman.h - mmap(), munmap(), posix MC3, not in kernel dir, not in beos, in 
*BSD

This is all I've got for now.  I have to work on some config files now.

Andrew

Other related posts: