<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    On 09/16/2011 09:04 PM, John Clements wrote:
    <blockquote
      cite="mid:2F94A8F5-7D64-4E20-A34B-65789A4BC479@brinckerhoff.org"
      type="cite">
      <pre wrap="">
On Sep 16, 2011, at 3:06 PM, John Clements wrote:

</pre>
      <blockquote type="cite">
        <pre wrap="">I'm trying to backport working FFI code to 5.1.3, and I'm having trouble referring to elements of a C struct. Specifically, in the presence of this definition

(define-cstruct _rack-audio-closure
 ([sound         _pointer]
  [cur-sample    _ulong]
  [num-samples   _ulong]
  [stop-now      _bool]
  [stop-sema-ptr _pointer]))

using the function (rack-audio-closure-cur-sample) on the result of an FFI call with signature

(_fun _pointer _ulong _pointer -&gt; _rack-audio-closure-pointer)

produces this error:

rack-audio-closure-cur-sample: expected argument of type &lt;struct:rack-audio-closure&gt;; given #&lt;cpointer:rack-audio-closure&gt;

in 5.1.3, but it works just fine in the git head.
</pre>
      </blockquote>
      <pre wrap="">
More research suggests that the problem is more limited; it looks like a problem of generativity. That is, if I have two modules that declare the "same" cstruct (same name, same fields, same types) then cpointers to these structures returned by functions from the first module cannot be accessed in the other module.</pre>
    </blockquote>
    <br>
    in 5.1.3 "same" cstructs defined in two different modules could not
    inter-operate.<br>
    Each place has it own copy of modules, so <br>
    the "same" cstruct defined in the same module but in two different
    places wouldn't inter-operate either.<br>
    Hence the change.<br>
    <pre wrap="">

AFAICT, This is not the case in more recent versions; that is, these cstructs are not generative.  Assuming this is deliberate, I could document it.</pre>
    This is deliberate.  It allows foreign pointers to be shared between
    places.<br>
    <br>
    The following text was removed from the documentation in the head
    version because cstructs are not generative anymore.<br>
    <br>
    Note that tags are compared with @racket[eq?] (or @racket[memq]),
    which means<br>
    an interface can hide its value from users (e.g., not provide the<br>
    @racket[cpointer-tag] accessor), which makes such pointers
    un-fake-able.<br>
    <br>
    If you would like document the fact that cstructs are generative
    only up to version 5.1.3.  I think that improve the docs.<br>
    Thanks,<br>
    <br>
    Kevin<br>
    <blockquote
      cite="mid:2F94A8F5-7D64-4E20-A34B-65789A4BC479@brinckerhoff.org"
      type="cite">
      <pre wrap="">

John

</pre>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_________________________________________________
  For list-related administrative tasks:
  <a class="moz-txt-link-freetext" href="http://lists.racket-lang.org/listinfo/dev">http://lists.racket-lang.org/listinfo/dev</a></pre>
    </blockquote>
    <br>
  </body>
</html>