[M3devel] CHAR vs. Ctypes.char?

[Jay K]

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