[M3devel] alignment in X.i3?

[Jay K]

While I did this to myself by accident, there is a "real" question buried here.
I forgot I was experimenting with:

Index: 32BITS/BasicCtypes.i3
===================================================================
RCS file: /usr/cvs/cm3/m3-libs/m3core/src/C/32BITS/BasicCtypes.i3,v
retrieving revision 1.13
diff -u -r1.13 BasicCtypes.i3
--- 32BITS/BasicCtypes.i3    11 Feb 2010 12:24:33 -0000    1.13
+++ 32BITS/BasicCtypes.i3    24 Jun 2010 09:54:01 -0000
@@ -11,15 +11,15 @@
 
 TYPE
   (* the four signed integer types *)
-  signed_char        = [-16_7f-1 .. 16_7f];
-  short_int          = [-16_7fff-1 .. 16_7fff];
-  int                = [-16_7fffffff-1 .. 16_7fffffff];
-  long_int           = [-16_7fffffff-1 .. 16_7fffffff];
-  long_long          = [-16_7fffffffffffffffL-1L .. 16_7fffffffffffffffL];
+  signed_char        = BITS 8 FOR [-16_7f-1 .. 16_7f];
+  short_int          = BITS 16 FOR [-16_7fff-1 .. 16_7fff];
+  int                = BITS 32 FOR [-16_7fffffff-1 .. 16_7fffffff];
+  long_int           = BITS 32 FOR [-16_7fffffff-1 .. 16_7fffffff];
+  long_long          = BITS 64 FOR [-16_7fffffffffffffffL-1L .. 16_7fffffffffffffffL];
 
   (* the four unsigned integer types *)
-  unsigned_char      = [16_0 .. 16_ff];
-  unsigned_short_int = [16_0 .. 16_ffff];
+  unsigned_char      = BITS 8 FOR [16_0 .. 16_ff];
+  unsigned_short_int = BITS 16 FOR [16_0 .. 16_ffff];
   unsigned_int       = Word.T;
   unsigned_long_int  = Word.T;
   unsigned_long_long = Long.T;
@@ -33,5 +33,3 @@
   char               = signed_char;
 
 END BasicCtypes.
-
-
Index: 64BITS/BasicCtypes.i3
===================================================================
RCS file: /usr/cvs/cm3/m3-libs/m3core/src/C/64BITS/BasicCtypes.i3,v
retrieving revision 1.8
diff -u -r1.8 BasicCtypes.i3
--- 64BITS/BasicCtypes.i3    13 Apr 2008 19:44:02 -0000    1.8
+++ 64BITS/BasicCtypes.i3    24 Jun 2010 09:54:01 -0000
@@ -11,16 +11,16 @@
 
 TYPE
   (* the four signed integer types *)
-  signed_char        = [-16_7f-1 .. 16_7f];
-  short_int          = [-16_7fff-1 .. 16_7fff];
-  int                = [-16_7fffffff-1 .. 16_7fffffff];
-  long_int           = [-16_7fffffffffffffff -1  .. 16_7fffffffffffffff ];
-  long_long          = [-16_7fffffffffffffffL-1L .. 16_7fffffffffffffffL];
+  signed_char        = BITS 8 FOR [-16_7f-1 .. 16_7f];
+  short_int          = BITS 16 FOR [-16_7fff-1 .. 16_7fff];
+  int                = BITS 32 FOR [-16_7fffffff-1 .. 16_7fffffff];
+  long_int           = BITS 64 FOR [-16_7fffffffffffffff -1  .. 16_7fffffffffffffff ];
+  long_long          = BITS 64 FOR [-16_7fffffffffffffffL-1L .. 16_7fffffffffffffffL];
 
   (* the four unsigned integer types *)
-  unsigned_char      = [16_0 .. 16_ff];
-  unsigned_short_int = [16_0 .. 16_ffff];
-  unsigned_int       = [16_0 .. 16_ffffffff];
+  unsigned_char      = BITS 8 FOR [16_0 .. 16_ff];
+  unsigned_short_int = BITS 16 FOR [16_0 .. 16_ffff];
+  unsigned_int       = BITS 32 FOR [16_0 .. 16_ffffffff];
   unsigned_long_int  = Word.T;
   unsigned_long_long = Long.T;
 
@@ -33,5 +33,3 @@
   char               = signed_char;
 
 END BasicCtypes.

and then I think there is a "hole" here:

  Int = int; Short = short; Long = long; Char = char;
  Bool      = Int;

  XMotionEvent = RECORD
     type: Int;             (* of event *)

(* 32bits padding for alignment here likely *)

     serial: unsigned_long; (* # of last request processed by server *)
     send_event: Bool;      (* true if this came from a SendEvent request *)

(* 32bits padding for alignment here likely also *)


     display: DisplayStar;  (* Display the event was read from *)
     window: Window;        (* "event" window reported relative to *)
     root: Window;          (* root window that the event occured on *)
     subwindow: Window;     (* child window *)
     time: Time;            (* milliseconds *)
     x, y: Int;             (* pointer x, y coordinates in event window *)
     x_root, y_root: Int;   (* coordinates relative to root *)
     state: unsigned_int;   (* key or button mask *)
     is_hint: Char;         (* detail *)
     same_screen: Bool      (* same screen flag *)
  END;


Am I write to be concerned with this cloning of header files?
Modula-3 probably inserts the holes/padding just like the C compiler probably inserts the holes/padding,
but it an area that deserves some extra close checking?


Like by passing the size of the record to some C that compares it to the size of the C type?
Or more aggressively the size/offset of each field?


Or maybe introducing a "more portable" C layer, where the "smallest" fields is an INTEGER or a LONGINT?


Or maybe soon someone else will apply some swig-like automation here, and generate the checks?


 - Jay


----------------------------------------
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Date: Thu, 24 Jun 2010 09:46:27 +0000
> Subject: [M3devel] alignment in X.i3?
>
>
> I don't suppose anyone else is seeing this?
>
> -- building in AMD64_DARWIN ---
>
> ignoring ../src/m3overrides
>
> new source -> compiling XMachine.i3
> new source -> compiling X.i3
> "../src/Common/X.i3", line 1376: Could not find a legal alignment for the packed type.
> "../src/Common/X.i3", line 1010: Could not find a legal alignment for the packed type.
> 2 errors encountered
> new source -> compiling Xatom.i3
> new source -> compiling Xmbuf.i3
>
> I'll keep digging..
>  - Jay
>
>