[M3commit] C typedefs for CARDINAL/LONGCARD?

[Tony Hosking]

Surely it is just as correct to write in C:

void foo (long cardinal);

A Modula-3 CARDINAL is assignable to a C long without any violation.

Of course, the C code loses the knowledge that the value "cardinal" is actually non-negative.
You'd need "assert(cardinal > 0)" in C to manually range-check on entry to foo.

Similarly, for Modula-3

foo(): CARDINAL

you'd need C:

long foo() {
  long result;
  ...
  assert(result > 0);
  return result;
}


Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 10 Apr 2010, at 08:07, Jay K wrote:

> > > add CARDINAL and LONGCARD as synonyms for ptrdiff_t and INT64
> 
>  
> As I see things, there are two approximations, and nothing "exact".
> INTEGER is exactly ptrdiff_t.
> LONGINT is exactly long long or __int64.
>  
>  
> CARDINAL is approx INTEGER (ptrdiff_t) and approx size_t, but neither is quite right.
> LONGCARD is approx LONGINT (long long/__int64) and approx unsigned long long/__int64, but neither is quite right.
>   The C unsigned types are "full range", but the Modula-3 unsigned types are "half range".
>  
>  
> Another approximation would be:
>  
>  
> typedef struct {
>   unsigned long or something value: 31 or 63;
> } CARDINAL;
>  
> typedef struct {
>   unsigned long long value: 63;
> } LONGCARD;
>  
> That is at least a way to get the correct positive "half range".
> but that's just worth wondering about -- passing small structs by value.
> There's probably no portable way to get a >32bit bit field on a 32bit system,
> even if there is "long long".
>  
> I view this kind of a stylistic thing, kind of a correctness thing.
>  
> If I have:
> <* EXTERNAL Interface__Foo*> PROCEDURE Foo(a: CARDINAL);
>  
> What should I write in C?
>  
> void Foo(size_t a) { }
> void Foo(ptrdiff_t a) { }
>  
> void Foo(CARDINAL a) { } This at least looks nice, but how does one make it correct?
>  
> Perhaps such a declaration just should not be written? Instead use INTEGER?
>  
> Imagine our C/Modula-3 interop story were so advanced, that we generated C header files
> from Modula-3 .i3 files. What then?
>  
>  
> Again, I'm willing to consider the option is "don't do that".
> Such an advanced system might just omit functions taking CARDINAL/LONGCARD.
>   After all -- where does the subrange check occur? If it is at the call, then
>   C code would too easily violate the safety.
>   If it is at the receipt, then the pattern I have too easily violates the safety
>    receiving the values in C.
>  
>  
> Again I'm open to the idea that CARDINAL/LONGCARD don't interoperate with C.
>  
>  
>  - Jay
>  
> > From: hosking at cs.purdue.edu
> > Date: Fri, 9 Apr 2010 13:00:40 -0400
> > To: jkrell at elego.de
> > CC: m3commit at elegosoft.com
> > Subject: Re: [M3commit] CVS Update: cm3
> > 
> > I'm not sure you want always to assume that. I find these synonyms a little misleading.
> > 
> > On 9 Apr 2010, at 11:35, Jay Krell wrote:
> > 
> > > CVSROOT: /usr/cvs
> > > Changes by: jkrell at birch. 10/04/09 11:35:54
> > > 
> > > Modified files:
> > > cm3/m3-libs/m3core/src/: m3core.h 
> > > 
> > > Log message:
> > > add CARDINAL and LONGCARD as synonyms for ptrdiff_t and INT64
> > 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3commit/attachments/20100410/1a9d79aa/attachment-0002.html>