[M3devel] darwin-generic waitpid?

[Tony Hosking]

Sure, I understand.  I think what you are doing is great for improving  
the reliability of the C-interface code.  Are you able to test all the  
platforms?  I am worried we are going to have bugs introduced that  
someone (you!) will need to chase down.

On 31 Dec 2008, at 11:09, Jay wrote:

>
> 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
>>