Problem with a DLL function

[Pablo_Novadep]

Good morning Rolf

I'm sorry to bother you again. I have advanced in the programming of the detector, with all the setups without problem. But i have a new "C programation" problem that i don't know how to resolve. The problem is with this function:

TRI_API TRI_tStatus TRI_SetDefaultAcquireTimeout (const struct timeval * theTimeout)

This function sets the default acquisition timeout, which is the time that the sensor waits for the X-ray trigger plus reads out the data

Parameters:
in - theTimeout the timeout the timeout should not exceed 65535 seconds
Returns:
Zero (0) for success. Otherwise non-zero.
Error Code:
-1: Input parameter invalid

I have searched the internet and found this about struct timeval and i find this: Defines the timeval structure that includes at least the following members:

- time_t tv_sec seconds
- suseconds_t tv_usec microseconds

With this information I have defined my function like this:

Introducing these parameters:

 

The system is waiting infinitely without returning anything.

I'm wrong  with the definition???

[rolfk]

Well, the problem with struct timeval is that it is a platform specifc definition.

Typically this is defined as follows:

struct timeval
{
    time_t         tv_sec;    //  seconds
    suseconds_t    tv_usec;   //  microseconds
};

Now time_t is a type definition that can vary in size between platforms.

It's not defined by the C Standard but rather a commonly used typedef in Posix style APIs. And the definition there is:

This is an integral value (integer) holding the number of seconds (not counting leap seconds) since a time epoch, usually the Posix time epoch of Jan 1, 1970 GMT.

suseconds_t is even less commonly defined. Most timeval defitions use here only simply an int as it only needs to go up to 999'999 to define the maximum number of microseconds in a second.

Traditionally time_t used to be a 32-bit integer but that poses a year 2038 problem if it is a signed integer and a year 2106 problem if treated as unsigned. So recent Unix C libraries for 64-bit platforms have started to use a 64-bit integer for this, making the simplified declaration of the timeval struct like this:

struct timeval
{
    int64      tv_sec;    //  seconds
    uint32_t   tv_usec;   //  microseconds
}

But under Windows it is only defined by the Winsock headers and here it always seems to use the long datatype for both elements, which under Windows is always a 32 bit signed integer.

In terms of your API use of this datatype is at least problematic for these reasons:

1) There is not properly defined standard what size the element of this structure should contain so depending on which compiler you use to compiler the calling program, the binary interface between caller and callee might not correspond. Under Unix, 32-bit applications usually use 32-bit integers and 64-bit variants should use a 64-bit integer.

2) Unless your API documentation states explicitly how this timeout value should be interpreted it is highly ambigious. It seems to use the structure as a relative time, which is not exactly what struct timeval is normally used for. But it could also use it as an absolute time, where you have to fill in the time in seconds since Jan 1, 1970 GMT at which the timeout should occur. Intuitively I would say it is interpreting it as a relative time, but there is absolutely no reason that it couldn't do it the other way too.

One other option could be that your API is not relying on a platform definition for this datatype under Windows, as it would otherwise have to pull in a Winsock header, which is highly unrelated and a bad code smell. Instead it might define this datatype in the header when compiled under non-Unix platforms.