[DGD] VS2005 Build Problem/Partial Solution

[MupMail]

Hi All,

A while back I posted about a problem with DGD built under windows using
VS2005 Pro. I finally had a spare moment today to look into this a
little further.

The problem occurs when the existing windows project is converted to a
2005 solution. Release will build fine but crash when you load the dgd
config and try to start the driver. Building in debug (which requires
the use of MFC as a shared dll to compile) will assert.

The assert is caused by the the memcpy call in the following code in time.c
////////////////////////////////////////////////////////////////////////////////////////////////////////////////
char *P_ctime(char *buf, Uint t)
{
    int offset;

    offset = 0;
    for (offset = 0; t > 2147397248; t -= 883612800, offset += 28) ;
    memcpy(buf, ctime((time_t *) &t), 26);
    if (offset != 0) {
    long year;
////////////////////////////////////////////////////////////////////////////////////////////////////////////////

I'm not certain as to the exact cause, but t which has a value of
something like 125495745 (can't remember exact value) when converted to
a time_t using (time_t*)&t ends up been a value along the lines of
678548584785944 much larger!

I believe this is been caused by 2005 using int64 for the time_t
representation. Placing a watch on t  and (time_t)t gives the same value
for both. But the moment you place a watch on (time_t*)&t gives a very
large 64bit value.

Is the Uint param that is been used for P_ctime a 32bit value? If so I'm
guessing that the forced typecast to a time_t in a default vs2005
installation is assuming that t is a 64bit value and thus reading past
the actual 32bits resulting in an incorrect value.

The way I've worked around the problem for now is to compile DGD using
32bit time structures rather than 64bit. This can be done with the
preprocessor define "_USE_32BIT_TIME_T".
Hopefully this problem will be resolved before 2038 ;)

Anyhow, with that defined, the solution builds fine and runs without
error :)

Hope the above is of some help and if anyone has an exact explanation
and fix for the above that allows 64bit times, I'd appreciate it.

Cheers,

Gary Preston.