sizeof(struct timeval)

[Tony Houghton]

I'm writing a python program which reads input device events so it needs
to know sizeof(struct timeval). By using the struct module I should be
able to work out sizeof(long) from python, but I can't think of a way to
measure non-fundamental types without including a little bit of C,
which I'd rather avoid.

How safe would I be assuming that

sizeof(struct timeval) == 2 * sizeof(long)

is always true on Linux on different architectures? AFAIK the input
device interface is Linux-specific so I don't need to worry about other
OS's.

 

[Big and Blue]

How safe would I be assuming that

sizeof(struct timeval) == 2 * sizeof(long)

is always true on Linux on different architectures?

Based on what I was looking at today (well, yesterday now), you might
be wrong.

I do know that the size of a struct utmp differs between a Linux
Itanium system and a Linux x86_64 system, and I seem to recall it migh be
related to timeval. I could be wrong - I wasn't interested in the timeval
part - but this part of the bits/utmp.h include file indicates the issue:


/* The ut_session and ut_tv fields must be the same size when compiled
32- and 64-bit. This allows data files and shared memory to be
shared between 32- and 64-bit applications. */
#if __WORDSIZE == 64 && defined __WORDSIZE_COMPAT32
int32_t ut_session; /* Session ID, used for windowing. */
struct
{
int32_t tv_sec; /* Seconds. */
int32_t tv_usec; /* Microseconds. */
} ut_tv; /* Time entry was made. */
#else
long int ut_session; /* Session ID, used for windowing. */
struct timeval ut_tv; /* Time entry was made. */
#endif

 

[Big and Blue]

>
> Based on what I was looking at today (well, yesterday now), you might
> be wrong.

However, it looks as though I was wrong:

linux/time.h:
struct timeval {
time_t tv_sec; /* seconds */
suseconds_t tv_usec; /* microseconds */
};

time.h:
typedef __time_t time_t;

sys/time.h:
typedef __suseconds_t suseconds_t;

bits/types.h:
__STD_TYPE __TIME_T_TYPE __time_t; /* Seconds since the Epoch. */
...
__STD_TYPE __SUSECONDS_T_TYPE __suseconds_t; /* Signed count of microseconds */


bits/typesizes.h:
#define __TIME_T_TYPE __SLONGWORD_TYPE
...
#define __SUSECONDS_T_TYPE __SLONGWORD_TYPE

bits/types.h:
#define __SLONGWORD_TYPE long int

 

[Tony Houghton]

In <[email protected]>,

Based on what I was looking at today (well, yesterday now), you might
be wrong.

I do know that the size of a struct utmp differs between a Linux
Itanium system and a Linux x86_64 system, and I seem to recall it migh be
related to timeval. I could be wrong - I wasn't interested in the timeval
part - but this part of the bits/utmp.h include file indicates the issue:

So is __WORDSIZE_COMPAT32 defined for one of Itanium or x86_64 but not
the other? The comment in the code below implies the opposite of what
you're saying: the size in 64-bit mode has to be the same as in 32-bit
mode, and as both CPUs have the same 32-bit architecture they should
therefore both use the same sized struct in 64-bit mode.

In any case, it does imply that timeval can be relied on to be 2 *
32-bits (2 * long) in 32-bit architectures and something else in 64-bit
architectures - where long is 64-bit.

 

[Tony Houghton]

In <[email protected]>,

However, it looks as though I was wrong:

[Snip headers showing my assumption is correct for his PC too]

I've already looked at those headers too. But most of the definitions
look like internal types and I'm not confident I can rely on them
staying the same size. But I don't think there's a strong enough case
for changing them to justify the glibc ABI change etc, so I'm probably
safe.

 

[David Bolt]

-

In any case, it does imply that timeval can be relied on to be 2 *
32-bits (2 * long) in 32-bit architectures and something else in 64-bit
architectures - where long is 64-bit.

Using the source below for a quick test on both a 32 and 64 bit SUSE
system[0], I get a size of 8 bytes on the 32 bit system, which implies 2
* 32 bit, and 16 ( 2 * 64 bit) on the 64 bit system.

<Source>
/*
quick, boring, and probably could do with a major cleanup
but it should be fine
*/
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
#include <sys/time.h>

int main(void)
{
int the_size=sizeof(struct timeval);
printf("%u\n", the_size);
exit(0);
}
</Source>


[0] see .sig for details.

Regards,
David Bolt

 

[Nick Kew]

I'm writing a python program which reads input device events so it needs
to know sizeof(struct timeval). By using the struct module I should be
able to work out sizeof(long) from python, but I can't think of a way to
measure non-fundamental types without including a little bit of C,
which I'd rather avoid.

How safe would I be assuming that

sizeof(struct timeval) == 2 * sizeof(long)

I've no idea.

But regardless of whether it's 'safe' amongst current devices,
you're setting yourself up for a Y2K-family bug. Except it'll
be a real one, not a storm-inna-teacup.

My python isn't up to sizeof issues either, so I can't help
you there. Either figure it out, or do it in C.

 

[Giovanni Bajo]

I'm writing a python program which reads input device events so it
needs to know sizeof(struct timeval). By using the struct module I
should be able to work out sizeof(long) from python, but I can't
think of a way to measure non-fundamental types without including a
little bit of C, which I'd rather avoid.

How safe would I be assuming that

sizeof(struct timeval) == 2 * sizeof(long)

is always true on Linux on different architectures? AFAIK the input
device interface is Linux-specific so I don't need to worry about
other OS's.

If I were you, I would write a Pyrex 4-liners which exposes this structure to
Python in the way you prefer. This would immediately fix all these
compatibility issues.

 

[rainbow.cougar]

Tony Houghton wrote:
...
But regardless of whether it's 'safe' amongst current devices,
you're setting yourself up for a Y2K-family bug. Except it'll
be a real one, not a storm-inna-teacup.

Hey, hey, don't go spouting off like one of those ignorant journalists!
I and a lot of other programmers wasted years debugging code ahead of
2000 to make darn sure the tempest stayed in the teacup. The code I
worked on sure as heck would have screwed over a bunch of Texans on
Medicaid, and I would have far preferred to be at my previous job
monitoring Space Shuttle data.


And in that Nick is correct, don't paint yourself into a corner.

Curtis