1) in wrapping a large widget with multiple interfaces using 
"strings", I sometimes allow the widget to copy a C-string into a 
Caml-allocated string - INCLUDING "overwriting" the terminating zero 
byte with zero... I wanted to make sure this was not seen as a major 
problem.

As I understand the Caml runtime's use of strings (at least one zero 
byte always being present), this does not seem like a problem to me - 
and until memory protection granularity practices change a lot, there 
should not be any trouble there... :)

2) this is about "future-proofing" (at the source level) code which 
interfaces with external [foreign] components and needs to store and 
pass around "opaque pointers": what is the best base Caml data type to 
use?

I currently use

type opaque_ptr = int32

I assume the other choices include int64, nativeint, or even int.

int64 - good if you know you are dealing with 64-bit values, obviously 
not suitable in the general case.

nativeint - this looks promising, as long as you do not need to deal 
with a 64-bit-int/32-bit-pointer model... would it be safe to assume 
that in any 64-bit Caml implementation, ints/pointers/"values" will 
ALL be 64-bit?

int - there clearly is a restriction on using only pointers with the 
low bit set to zero; if you can stipulate that this is a non-issue, 
then you can just SET/CLEAR the low bit at the Caml/C boundary and 
then be able to safely store to and retrieve from Caml "value" fields 
(I think).

So... is the winner int or nativeint?  Or ?  And yes, I know that 
using int will avoid an extra allocation... but are there other 
considerations not represented here?

Any relevant insights will be appreciated. :)

Robert Roessler
roessler@rftp.com
http://www.rftp.com