[M3devel] "cvsup compat"? (really, general source compat)

[Jay]

The subject isn't really the whole subject.
 
 
cvsup compat?
 

I could make the cvsup source highly compatible
with "all" Modula-3 distributions by giving it its own
"SupUnix.i3", implemented mostly in C, using INTEGER more
and LONGINT less. Even its own SchedulerPosix with Enable/DisableSwitching.
It would just, like, IMPORT SupUnix as Unix, IMPORT SupScheduler as SchedulerPosix,
leading to the overall source changes being small.

 
Or I could adapt it to current cm3, not compatible with any other older
versions or forks (ezm3, pm3, old cm3, etc.)
Use LONGINT. Use some of the slightly copying wrappers (Ugrp, Unetdb).
 

Thoughts?

 
Maintaining full source compat in cm3 itself I think is not an option.
But almost.
At least stat should always return 64bit file sizes.
  Or at least a 53bit double..I doubt that helps though.
Most of the rest of "problems" could be "fixed".
Such as by restoring a little bit of header cloning -- more for 
Ugrp and Unetdb, not Ustat, and verify the correctness in the C code.
  (because Ustat already has a place to copy an idealized type to,
whereas Ugrp and Unetdb don't, unless interfaces altered like I did.)
And using INTEGER more and LONGINT less.
 Not just because older compilers don't support LONGINT, but because
  code that uses one is not compatible with interfaces that use the other,
  even on 64bit platforms where they are "the same".
  (like on 32bit platforms, in C, int* and long* are compatible).
 I'd have to do more research though, like on ino_t and dev_t.
 They are 64bits on Linux/AMD64, I don't know if they ever are on any
   32bit platforms, in which case LONGINT comes back.
   (other point here is LONGINT or, really, my preference, INT64 and UINT64
   should have been added to the language over 10 years ago, then these
   would have been smoothed out by now..oh well..or possibly INTEGER
   and LONGINT should be more source compatible, but I realize there
   are arguments against some of that -- you could make it so on 
   64bit, but then a bunch of code would be produced that only compiled
   on 64bit platforms.)
 

I'll probably go ahead and adapt it to current cm3.
The other option can be explored later independently.
Could be that nothing but current cm3 matters much.
 

 - Jay