Technically, a C compiler on a 64 bit OS can be completely compliant if it uses 32 bits for unsigned long . There is no requirement in C that 64 bits be used if they are available.
gpssim.h says that
typedef struct
{
int week; /*!< GPS week number (since January 1980) */
double sec; /*!< second inside the GPS \a week */
} gpstime_t;
The maximum number of seconds in one week is 604800 (or 604801 perhaps with a leap second), so using either uint32 or uint64 would work for this purpose.
However: In C, when you divide integers, you truncate towards zero; https://stackoverflow.com/questions/3602827/what-is-the-behavior-of-integer-division . This is not the same as in MATLAB: when you divide 32 or fewer bit integer data types in MATLAB, the operation is carried out "as if" the values were converted to double, the operation done on double, and then the result cast to the integer data type. This may sound the same, but it is not: in MATLAB, when you cast a floating point number to an integer data type, the value is rounded . Observe:
uint32(3)/uint32(2)
This is because it was carried out "as if" 3.0/2.0 were calculated, giving 1.5, and then uint32(1.5) rounds to uint32(2)
Because of this, equivalent code in MATLAB to the C could would be
g0.week = g.week;
g0.sec = floor(floor(g.sec + 0.5)/30) * 30;
wn = uint32(mod(g0.week, 1024)); %or uint64 depending on compiler
tow = uint32(floor(floor(g0.sec) / 6)); %or uint64 depending on compiler
On the other hand, because of the way you constructed g0.sec you can be sure that it is the floating point representation of an integer, and is exactly divisible by 6 (since it is an exact multiple of 30), so the last line could be optimized to
tow = uint32(g0.sec / 6); %or uint64 depending on compiler
