Ffi Dlsym

The semantics of the dlsym seem non-obvious.

In particular, the experiments that Jesse and PnkFelix did (see OsdepDynload) indicate that the behavior when one does not provide a handle is platform dependent.

---

Derick Eddington has pointed out that [source:trunk/larceny_src/doc/LarcenyNotes/note7-ffi.html Larceny Note 7] claims that dlsym supports passing #f for the handle argument:

As a special case, handle can be #f, which means that the symbol will be resolved in the symbol table of the running program. Using this feature is generally not advisable, as no promises are made about the names in the Larceny executable.

Derick also pointed out that the claim above is inconsistent with the current behavior of Larceny.

PnkFelix is not surprised if that note is inaccurate (it is vastly out of date), but he is also spending some time trying to determine when this change in the semantics was introduced, since we currently signal a pretty explicit error when one passed #f as the handle argument.

• The relevant bits of code from the trunk (aka current development tree) are:
• [source:trunk/larceny_src/lib/Ffi/ffi-lower.sch ffi-lower.sch]
• [source:trunk/larceny_src/src/Lib/Common/system-interface.sch#L351 system-interface.sch]
• [source:trunk/larceny_src/src/Rts/Sys/ffi.c ffi.c]
• [source:trunk/larceny_src/src/Rts/Sys/osdep-unix.c osdep-unix.c]
• The relevant parts of those files have not changed since I merged Lars' [source:branches/release_2/larceny_src release_2 branch] into the trunk of our source repository, way back in changeset:2543.
• I continued back to the state of the code before that merge, focusing mostly on the [source:branches/release_2/larceny_src release_2 branch] rather than the [source:trunk/larceny_src@2541 trunk at that time] because Lars was focusing his development efforts on [source:branches/release_2/larceny_src that branch] while Will worked on the trunk, and therefore the majority of the relevant revisions to the FFI were on the release_2 branch.
• So, on the [source:branches/release_2/larceny_src release_2 branch],
  • [source:branches/release_2/larceny_src/Ffi/ffi-lower.sch ffi-lower.sch]
  • [source:branches/release_2/larceny_src/Lib/Common/system-interface.sch#L232 system-interface.sch]
  • [source:branches/release_2/larceny_src/Rts/Sys/ffi.c ffi.c]
  • [source:branches/release_2/larceny_src/Rts/Sys/osdep-unix.c osdep-unix.c]
• In fact, I provided the C files above to try to be complete, but one can see how this code handles a #f handle without looking at the C code.
• Just tracing the control flow of ffi/dlsym in [source:branches/release_2/larceny_src/Ffi/ffi-lower.sch#L17 ffi-lower.sch], one can see that it calls out directly to sys$C-ffi-dlsym without attempting to convert the handle argument. The sys$C-ffi-dlsym procedure is in [source:branches/release_2/larceny_src/Lib/Common/system-interface.sch#L232 system-interface.sch], and that invokes error if the argument is not an exact integer.
• Furthermore, according to the annotate output (available via a link at the top of the trac-rendered source code), that is the way the code was when it was initially checked in way back in changeset:883.
• It is possible that Lars meant to write 0 rather than #f in Larceny Note 7. That would make a lot more sense, especially given the experiments that Jesse and PnkFelix did with OsdepDynload.