[M3devel] CHAR vs. Ctypes.char?

[Jay K]

ADR should be "less unsafe".
Perhaps in general Modula-3 "unsafe" can/should be "less unsafe".
e.g. "Only as unsafe as needed to get the 'usual' job done, and no more".
 
 
Imagine if the types involved actually changed in some other way.
LOOPHOLE would likely make almost anything compile.
Whereas my other suggestions add a significant amount of type checking and deliberately fail to compile many incorrect forms.
 
 
There is not, or should be, this "harsh" line where there are no rules or static checking in unsafe code.
There is still a significant amount of checking and a significant confidence that if it compiles, it has a certain amount of correctness and "odds" of working. I've written a lot of C code, even recently. It's not just a lost cause.
 
 
 
 - Jay

----------------------------------------
> From: hosking at cs.purdue.edu
> To: jay.krell at cornell.edu
> Date: Wed, 23 Jun 2010 19:09:35 -0400
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] CHAR vs. Ctypes.char?
>
> ADR isn't safe so why not just LOOPHOLE?
>
> Sent from my iPhone
>
> On Jun 23, 2010, at 6:52 PM, Jay K wrote:
>
>>
>> Something should change.
>> I'm not sure exactly what but I'll make some suggestions.
>>
>>
>> char_star changed from UNTRACED REF char to UNTRACED REF CHAR
>> Probably not this.
>> Possibly introduce Utypes.char_star = UNTRACED REF CHAR
>> but leave Ctypes.char_star alone. Possibly. This is I think the
>> least
>> likely option.
>>
>>
>> and/or
>>
>>
>> Utypes.CHAR_star introduced = UNTRACED REF CHAR
>> many uses of char_star in m3core/src/unix changed to CHAR_star
>>
>>
>> and/or
>>
>>
>> Text.i3 already has FromChars that takes array of CHAR
>> add function FromCChars or somesuch that takes array of Ctypes.char
>> This I think is most likely.
>> Even though it adds to a "standard" interface.
>> It could be TextEx or TextExtras or such if that helps.
>>
>>
>> In particular, we often have:
>>
>>
>> Unix.i3: PROCEDURE GetFoo(char_star);
>>
>>
>> Wrapper.i3:
>> PROCEDURE GetFoo():TEXT=
>> VAR buff; ARRAY [0..N] of CHAR;
>> BEGIN
>> Unix.GetFoo(ADR(buff[0]));
>> RETURN Text.FromChars(buff);
>> END GetFoo;
>>
>>
>> This doesn't work with -new_adr.
>> because ADR(CHAR) != ADR(char).
>>
>>
>> At a minimum you have to:
>> Unix.GetFoo(LOOPHOLE(ADR(buff[0]), ADDRESS));
>>
>>
>> but I'd much rather something more typesafe.
>>
>>
>> e.g.:
>> Wrapper.i3:
>> PROCEDURE GetFoo():TEXT=
>> VAR buff; ARRAY [0..N] of Ctypes.char;
>> BEGIN
>> Unix.GetFoo(ADR(buff[0]));
>> RETURN Text.FromCChars(buff);
>> END GetFoo;
>>
>> or
>>
>> Unix.i3:
>> PROCEDURE GetFoo(CHAR_star);
>>
>> Wrapper.i3:
>> PROCEDURE GetFoo():TEXT=
>> VAR buff; ARRAY [0..N] of CHAR;
>> BEGIN
>> Unix.GetFoo(ADR(buff[0]));
>> RETURN Text.FromChars(buff);
>> END GetFoo;
>>
>>
>> or even something fancier like:
>>
>>
>> Unix.i3:
>> PROCEDURE GetFoo():TEXT; !
>>
>>
>>
>> To whatever extent this occurs in sysutils, if at all, probably have
>> to just LOOPHOLE,
>> since it needs to be compatible with a mix of compilers and m3core.
>>
>>
>> - Jay
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> ----------------------------------------
>>> Subject: Re: [M3devel] CHAR vs. Ctypes.char?
>>> From: hosking at cs.purdue.edu
>>> Date: Wed, 23 Jun 2010 09:57:04 -0400
>>> CC: m3devel at elegosoft.com
>>> To: jay.krell at cornell.edu
>>>
>>> CHAR is an enumeration.
>>> Ctypes.char is a subrange.
>>>
>>> Never the twain shall meet.
>>>
>>> On 23 Jun 2010, at 09:40, Jay K wrote:
>>>
>>>>
>>>> Is it deliberate that CHAR and Ctypes.char don't match?
>>>> I'm building the tree with -new_adr.
>>>> "Many" of the breaks are due to this mismatch. Not real bugs. I
>>>> use LOOPHOLE to let it compile.
>>>> "Many" are due to socklen_t. Real bugs on 64bit problems, at least
>>>> in head.
>>>> I'm not sure there are any others yet.
>>>>
>>>> - Jay
>>>>
>>>
>>