[M3devel] another size/alignment/interop problem..

[Jay K]

We require some degree of C interop, so we require some degree of predictable layout.
What we have falls below my expectations, but perhaps if it is explained to me, it won't any longer.
Well, I guess we don't really require any predictable layout. I can give up on records for any interop and rely strictly on integer and pointer parameters. Or, well, I can do like for Posix and use a small copying layer and smush out anything vaguely unclear like this...

 - Jay


> Date: Sun, 1 Sep 2013 17:07:31 -0500
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] another size/alignment/interop problem..
> 
> 
> 
> On 08/31/2013 10:05 PM, Jay K wrote:
> >   TYPE FILETIME = RECORD
> >      dwLowDateTime : uint32_t;
> >      dwHighDateTime: uint32_t;
> >    END;
> >
> >    BY_HANDLE_FILE_INFORMATION = RECORD
> >      dwFileAttributes    : uint32_t;
> >      ftCreationTime      : FILETIME; (* This should be at offset 4 but is 8 on  64bit systems. *)
> >      (* the rest omitted *)
> >    END;
> >
> >
> > Why doesn't that just work?
> 
> The only explanation I can think of is that the compiler gave record type FILETIME
> 64-bit alignment.  As far as I know, there is nothing in the language that says it
> is not perfectly within its rights to do so.  Why is another question.
> 
> 
> > It works with:
> >   TYPE FILETIME = BITS 64 FOR RECORD
> >
> 
> Which is consistent with the language, if it doesn't refuse altogether.
> >
> >   but imho it should work without that.
> >
> >
> >    - Jay
> >
> >
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130901/cbd7e67e/attachment-0002.html>