Skip to content


New comment on block [block-idp11616480] #1701

ghost opened this Issue · 5 comments

2 participants


This is where the approach followed by Ctypes (and other FFIs based on similar ideas, e.g. Haskell's) breaks badly. Nowhere in the POSIX standard is this exact definition of struct timeval guaranteed. The only guarantee is that it's a struct with at least fields tv_sec and tv_usec, not necessarily in this order. A quick Google search shows this actual definition for instance:

struct timeval {
#ifdef sparc64
uint32_t pad;
time_t tv_sec;
#ifdef __alpha

uint32_t __pad;
suseconds_t tv_usec;


This comment references this from milestone beta1:


Let's improve the timer function that we wrote earlier. The POSIX function gettimeofday retrieves the time with microsecond resolution. The signature of gettimeofday is as follows, including the structure definitions.

Agreed. We've got a couple of strategies to deal with this in upcoming versions of ctypes (/cc @yallop):

  • A configure-time check to determine the layout on the current host to determine the precise layout.
  • Generate concrete C stubs at compile-time (via an IDL similar to camlidl) from the Ctypes definition, which gives us close to the same performance as the existing FFI, but with considerably more safety guarantees about the generated stubs.
  • (longer term) a meta-programming technique to perform Ctypes expansion at runtime too.

The important feature is that the Ctypes definitions are separate from the module that invokes the call (Foreign, currently). This lets us keep defining Ctypes for more libraries, and work on the runtime side separately.

Note that I've got a half-finished chapter with the details of the normal FFI, but a full explanation blew our page budget considerably. I'm currently planning to finish the chapter post-publication and make it an online-only supplement, but could wrestle it into the current edition if you feel strongly that it's needed.


Section on alternatives added to beta3, and also explanation of how to probe for struct offsets by generating C code. This hasn't been released in an official ctypes yet, but it's been committed and is being polished now.

@avsm avsm closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.