[racket] FFI question: 0 microseconds returned from gettimeofday call

From: Thomas Chust (chust at web.de)
Date: Fri Jul 15 21:37:29 EDT 2011

keydana at gmx.de wrote:
> [...]
> Well in this case in fact, I was happy with the result, the 1 looked fine given we're having daylight saving time :-;
> [...]

Hello Sigrid,

sure the one is fine, but I think this field really never contains
anything else than 1 when DST is in effect or 0 when it's not, so it has
a boolean meaning.

> [...]
> If tp is NULL and tzp is non-NULL, gettimeofday() will populate the timezone struct in tzp.  If tp is non-NULL and tzp is NULL, then only the timeval struct in tp is populated. If both tp and tzp are NULL, nothing is returned.
> I was wondering whether this really meant the caller had to specify a different kind of pointer (null or non null) in a variable designed for OUTPUT/return... this sounded illogical somehow, but  in any case, using Racket (_ptr o _timeval) seems to have worked - meaning that Racket does NOT provide a null pointer here I guess?
> [...]

Correct, the caller has to provide a storage location for the output
she's interested in and may pass NULL to indicate that no storage has
been allocated because she's not interested in a return value.

This is a common convention for C functions. Of course there can also be
functions that always expect an output parameter to point to a valid
storage location and that always write to the address indicated.

In C++ output parameters are often declared using reference types, which
are a special kind of pointer types that is always implicitly
dereferenced when used in expressions and cannot be set to NULL
explicitly (at least not if the expression used to do so is simple
enough for the compiler to realize what you're up to ;-)

If you declare a (_ptr o _something) type, racket always allocates space
for a something, passes the pointer to the foreign function and then
dereferences it to extract the _something after the foreign function
returns. Racket should indeed never pass a NULL pointer here.


When C++ is your hammer, every problem looks like your thumb.

Posted on the users mailing list.