sizeof(struct timeval)

**Big and Blue** · Mar 14 '06, 01:45 AM

Re: sizeof(struct timeval)

Tony Houghton wrote:[color=blue]
>
> How safe would I be assuming that
>
> sizeof(struct timeval) == 2 * sizeof(long)
>
> is always true on Linux on different architectures?[/color]

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** · Mar 14 '06, 01:55 AM

Re: sizeof(struct timeval)

Big and Blue wrote:[color=blue]
> Tony Houghton wrote:[color=green]
>>
>> How safe would I be assuming that
>> sizeof(struct timeval) == 2 * sizeof(long)
>>
>> is always true on Linux on different architectures?[/color]
>
> Based on what I was looking at today (well, yesterday now), you might
> be wrong.[/color]

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** · Mar 14 '06, 02:45 AM

Re: sizeof(struct timeval)

In <DcmdnRkLxJg4gY vZRVnyrw@pipex. net>,
Big and Blue <No_4@dsl.pipex .com> wrote:
[color=blue]
> Tony Houghton wrote:[color=green]
>>
>> How safe would I be assuming that
>>
>> sizeof(struct timeval) == 2 * sizeof(long)
>>
>> is always true on Linux on different architectures?[/color]
>
> 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:[/color]

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.
[color=blue]
> /* 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[/color]

--
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** · Mar 14 '06, 02:45 AM

Re: sizeof(struct timeval)

In <cuqdnbf1lLdLgo vZRVnyhA@pipex. net>,
Big and Blue <No_4@dsl.pipex .com> wrote:
[color=blue]
> Big and Blue wrote:[color=green]
> > Tony Houghton wrote:[color=darkred]
> >>
> >> How safe would I be assuming that
> >> sizeof(struct timeval) == 2 * sizeof(long)
> >>
> >> is always true on Linux on different architectures?[/color]
> >
> > Based on what I was looking at today (well, yesterday now), you might
> > be wrong.[/color]
>
> However, it looks as though I was wrong:[/color]

[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** · Mar 14 '06, 04:55 AM

Re: sizeof(struct timeval)

On Tue, 14 Mar 2006, Tony Houghton <this.address.i s.fake@realh.co .uk>
wrote:-

<snip>
[color=blue]
>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.[/color]

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** · Mar 14 '06, 09:15 AM

Re: sizeof(struct timeval)

Tony Houghton wrote:[color=blue]
> 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)[/color]

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** · Mar 14 '06, 10:45 AM

Re: sizeof(struct timeval)

Tony Houghton wrote:
[color=blue]
> 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.[/color]

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@gmail.com** · Mar 15 '06, 02:45 PM

Re: sizeof(struct timeval)

Nick Kew wrote:[color=blue]
> 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.
>[/color]

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

sizeof(struct timeval)

sizeof(struct timeval)

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment