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. _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users
