[M3devel] darwin-generic waitpid?

[Jay]

I'd like to avoid cloning any headers, and use clear portable C wrappers to bridge between Modula-3 and stuff written/declared in C. e.g. no bit fields.
 
These are contrary goals.
 
Or, at least, only clone headers that are essentially identical across all Posix platforms, or which the only variables are endianness and word size.
 
There are a few possible compromises.
Currently there is linux-common, openbsd-common.
I would NOT like to add netbsd-common, freebsd-common, solaris-common.
As such, I'm pushing stuff from "*-common" to plain "Common".
 
As well, by not cloning header content that is unused in the cm3 tree, much is saved.
 Compare the number of lines in LINUXLIBC6 vs. linux-common.
But I'd like to get further than that.
 
Similarly, not cloning header content that doesn't present a portable interface, which tends to lead to it not being used, since most of the cm3 code is factored only on Posix vs. Win32, and not one Posix superset or another.
 
I also believe that C is "everywhere" and will remain "everywhere".
Except very constrained "safe" environments like a web browser or Java-only Google phone, where Modula-3 is about as far as being able to run as C is.
 
I think C wrappers are very preferable to cloning headers.
 
The endian-ness is actually abstracted out in normal C code.
There's the various macros for cracking the 32 bit status.
Ok, maybe that is apples and oranges. It is abstracted out in the client C code and the client Modula-3 code, except that Modula-3 client code uses LOOPHOLE. Both the C headers and Modula-3 headers are "messy", the C headers sometimes more so, such as to cater to other (BSD) interfaces.
 
I realize there are the Win32 headers to be concerned with as well.
 
 - Jay

----------------------------------------
> From: hosking at cs.purdue.edu
> To: jay.krell at cornell.edu
> Date: Wed, 31 Dec 2008 10:47:46 +1100
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] darwin-generic waitpid?
>
> On 30 Dec 2008, at 18:51, Jay wrote:
>
>>
>> It looks like waitpid's output is endian-dependent, and that
>> therefore darwin-generic is wrong on some architectures, asis linux-
>> common and openbsd-common.
>>
>>
>> I expect to fix this shortly, by replacing all the Modula-3 result
>> bitfields with uint8_t and
>> having a C wrapper do the translation.
>
> I am concerned that so much C wrapper stuff is starting to creep in.
> I want to be able to see the endianness in the Modula-3 code, not have
> it squirrelled away in C code. What if I don't have a C compiler?
> Jay, please be careful with your assumptions about platforms always
> having C.
>
>> As well, for increased portability, the flags will be input uint8_t
>> fields in the record, rather than platform-dependent flags.
>>
>>
>> - Jay
>