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.

--
The address in the Reply-To is genuine and should not be edited.
See <http://www.realh.co.uk/contact.html> for more reliable contact addresses.

[Big and Blue]

Tony Houghton wrote:

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_COMP AT32
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
--
Just because I've written it doesn't mean that
either you or I have to believe it.

[Big and Blue]

Big and Blue wrote:

Tony Houghton wrote:

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.

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_T YPE __suseconds_t; /* Signed count of microseconds */
bits/typesizes.h:
#define __TIME_T_TYPE __SLONGWORD_TYP E
...
#define __SUSECONDS_T_T YPE __SLONGWORD_TYP E

bits/types.h:
#define __SLONGWORD_TYP E long int

--
Just because I've written it doesn't mean that
either you or I have to believe it.

[Tony Houghton]

In <Dc************ ********@pipex. net>,
Big and Blue <No**@dsl.pipex .com> wrote:

Tony Houghton wrote:

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:

So is __WORDSIZE_COMP AT32 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.
/* 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_COMP AT32
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

--
The address in the Reply-To is genuine and should not be edited.
See <http://www.realh.co.uk/contact.html> for more reliable contact addresses.

[Tony Houghton]

In <cu************ ********@pipex. net>,
Big and Blue <No**@dsl.pipex .com> wrote:

Big and Blue wrote:

Tony Houghton wrote:

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.

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.

--
The address in the Reply-To is genuine and should not be edited.
See <http://www.realh.co.uk/contact.html> for more reliable contact addresses.

[David Bolt]

On Tue, 14 Mar 2006, Tony Houghton <th************ ******@realh.co .uk>
wrote:-

<snip>

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
architecture s - 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

--
Member of Team Acorn checking nodes at 50 Mnodes/s: http://www.distributed.net/
AMD1800 1Gb WinXP/SUSE 9.3 | AMD2400 256Mb SuSE 9.0 | A3010 4Mb RISCOS 3.11
AMD2400(32) 768Mb SUSE 10.0 | RPC600 129Mb RISCOS 3.6 | Falcon 14Mb TOS 4.02
AMD2600(64) 512Mb SUSE 10.0 | A4000 4Mb RISCOS 3.11 | STE 4Mb TOS 1.62

[Nick Kew]

Tony Houghton wrote:

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.

--
Nick Kew

[Giovanni Bajo]

Tony Houghton wrote:

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.
--
Giovanni Bajo

[rainbow.cougar]

Nick Kew wrote:

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