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

Hi Thomas,

thanks a lot for your quick answer! 


> :-/ Perhaps _long or _intptr would be a better choice than _int, since
> they would adapt to the system's word size, which is more likely to be
> right everywhere than _int that is always 32 bits wide, according to the
> Racket documentation, but you can't be sure.


In fact, I've already experimented with _int64,  which gave me similar - and very strange! -results as these two ... the result always is either 6 (looking like real microseconds :-;), or 10, or 16 digits long (examples would be: 
644199
4295162899
9359042975779072
), and when I reexecute the code several times in a row, the results very often seem to look like the example in the middle, starting with digits 4295... and having a length of 10... (sorry if this sounds a bit silly, but...)
What kind of magic might this be...?

> 
> There is, however, a PLaneT package (planet dherman/c:4:0) providing the
> facilities to parse header files and extract structure layout
> information like that required here using the system's C compiler.


Thanks for the pointer (pun intended :-;), I will have a look... But in fact I hope that other than experimenting with calls like these, that is, when working with a "real", user-friendly library, I will not have too great a need to use it :-)

> 
> The zero microseconds value could mean that you were actually "lucky"
> with the call, that your system simply doesn't support time values with
> microsecond precision or that your system's implementation of
> gettimeofday doesn't support that.


Well, I think I should at least get the milliseconds, because Racket has them in (current-milliseconds), so in that case I'd expect to see something like 123000 in the microsecond field...
I want to have a look at dtrace as soon as I have time (it seems to work a bit less straightforward than strace :-;) to see how Racket does it,- or of course I might check out the sources...

> 
> By the way, I think that the dsttime field in _timezone should probably
> have the type _bool. But the POSIX standard says anyway that if the
> second argument to gettimeofday is anything else than the null pointer,
> the behaviour of the whole function call is undefined, so you have no
> right to complain no matter how strange the result is ;-)

Well in this case in fact, I was happy with the result, the 1 looked fine given we're having daylight saving time :-; But your remark reminds me of another part of the man page that was not clear to me:

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?

> 
> Welcome to the world of C -- I guess my e-mail signature sums up the
> situation in this case, too ;-)

Well thank you - as long as you know you're a visitor only, you can stay relaxed, and just gaze at all the ancient curiosities (or so I hope, for now :-;)

Thanks again for your patience with the c foreigners,
Sigrid


> 
> Ciao,
> Thomas
> 
> 
> -- 
> When C++ is your hammer, every problem looks like your thumb.