[M3devel] CHAR vs. Ctypes.char?

[Jay K]

oops...perhaps LOOPHOLE to "CHAR_star" or "char_star" not so bad.
  Program can read locally and decide quickly that basically char==CHAR and casting related to moving between them not so bad. If the types "really" change, it'd be to WCHAR or such and the LOOPHOLE to CHAR/char_star would still fail to compile.
 
LOOPHOLE to ADDRESS is what I'm avoiding.
 
?
 
Still, I like the idea of Text.FromCtypesChars() or such.
 
 
 - Jay


----------------------------------------
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> Date: Thu, 24 Jun 2010 02:24:47 +0000
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] CHAR vs. Ctypes.char?
>
>
> 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
>>>>>
>>>>
>>>