[openbeos] sys/stat.h and related commits
- From: "Andrew Bachmann" <shatty@xxxxxxxxxxxxx>
- To: "openbeos" <openbeos@xxxxxxxxxxxxx>
- Date: Sat, 02 Aug 2003 02:25:57 -0700 PDT
Okay, I know I said I was going to wait, but since the changes turned out to be
more minimal
than I thought, I simply went through them one by one and convinced myself that
they were
okay, and then performed them. There should now be no more and no less errors
than there
were before, and at most only 1 or 2 more warnings. (I sort of lost track of
the warnings)
We now have a new stdbool.h header and a revised and more complete stdint.h.
stddef.h is now
free of gnu. All the while I have been following that nicely searchable posix
spec: http://
www.opengroup.org/onlinepubs/007904975/toc.htm
I have been able to run configure for libiconv against our headers and also run
make successfully
using that configuration.
While going through the posix headers I was fairly distressed to see the extent
to which OS.h has
been inherited, primarily because of its inclusion in sys/socketvar.h. It can
not be removed from
sys/socketvar.h because sys/socketvar.h uses semaphores.
I would like to float a proposal to move some subparts of OS.h into separate
files that can be
included directly. (and would also be included by OS.h, of course) For
example, perhaps these
could be together in a header, (KernelTypes.h?) preferably defined in terms of
<sys/types.h>
instead of SupportDefs.h:
typedef int32 area_id;
typedef int32 port_id;
typedef int32 sem_id;
typedef int32 team_id;
typedef int32 thread_id;
We may also want to include the related structs for those types in that header.
My goal isn't
necessarily to accomplish some high principle, but rather to attack the
pragmatic issue of
reducing the beos fallout that comes through when posix headers are included.
As many others
are probably aware, there are little things that sneak through that make
porting apps annoying
and/or difficult. As such, I think it's reasonable to have another header that
groups together just
the pieces that we need from the posix side. Such a header need not
necessarily be useful to the
average beos app.
Andrew
Other related posts:
