Re: [Xen-devel] [PATCH v6 02/13] cxenstored: add support for systemd active sockets

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

On 18 Jul 2014, at 00:13, Luis R. Rodriguez <mcgrof@xxxxxxxx> wrote:
> On Thu, Jul 17, 2014 at 08:16:40PM +0000, Dave Scott wrote:
>> 
>> If the strings compare equal with ‘strcmp’ then I would have thought either
>> would work, unless the consumer is holding onto the string pointer for longer
>> than the call duration. As soon as your function returns (or allocates) the
>> OCaml strings can be moved around which invalidates the result of String_val—
>> perhaps this is the cause of the difference between the String_val result and
>> your static strings?
> 
> Your description gave me enough confidence to go ahead and test this without
> the added null characters and for some reason now it all works. I'll respin
> and send a v7.

The heap layout of OCaml strings is described precisely in Real World OCaml 
here:
https://realworldocaml.org/v1/en/html/memory-representation-of-values.html#string-values

Nul-termination is guaranteed by the representation (via the padding byte) to
make it easier to pass to-and-from C functions.  OCaml itself tracks the
length of the string explicitly, so it doesn't care if there are NUL values
within it (although this will of course make it difficult to pass to-and-from
C string functions, and care should be taken only to pass NUL-containing
OCaml strings to mem* functions instead of str*).

>>> String_val() is used for the static string connect_to passed to the
>>> C wrapper, the String_val() documentation [0] says that "there is a null
>>> character after the last character in the string" however its unclear
>>> if this is guaranteed if the string was originally a static Ocaml string
>>> which was not null terminated.

In other words, trust the OCaml manual just as you trusted the snprintf
man page :-)

-anil
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel