Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
C interface and representation
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 1998-10-27 (19:01)
From: Don Syme <dsyme@m...>
Subject: C interface and representation

I think we'd all agree that the O'Caml-C interface reveals rather a lot 
about the runtime layout of various O'Caml types.  For example,
it reveals that record types are represented as tuples.  

I'm wondering if the O'Caml compiler could emit a set of C macros that
effectively hides these representation choices.  For example,
for a file

  type abc = { flag1 : bool; flag2: bool; flag3: bool }

ocamlc {some option} > foo.h

could generate C macros like
#define Foo__abc__flag1(value) ...
#define Foo__abc__flag2(value) ...
#define Foo__abc__flag3(value) ...

(where each of these are lvalues)

This would, of course, make C code that creates and manipulates
record valuables more robust, since it would be independent of the
record ordering.  I have a current application that creates record
values with 10-20 fields (many of them boolean flags), and it is
just silly to hardwire field numbers.  Such records will probably
be common in any interface to substantial APIs (I have in mind various
Microsoft APIs).

It may also be plausible for the compiler team to optimize the layout of
records such as the one above at a later date.  Any self respecting 
C programmer would expect the above record to consume 1 byte, and it would
be nice to at least allow for the possibility of such optimizations,
wouldn't it, without breaking C code?  (Or, alternatively, to allow
for a richer type representation description language that, for example,
specified field widths)

[ Actually, I've glossed over the fact that bits are not lvalues
in C, so both "set" and "get" macros may be required.  Also, marshalling
and so on would be affected by such optimizations, but that's another story.