473,322 Members | 1,526 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,322 software developers and data experts.

sizeof(struct timeval)

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.
Mar 14 '06 #1
8 5868
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_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
--
Just because I've written it doesn't mean that
either you or I have to believe it.
Mar 14 '06 #2
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_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

--
Just because I've written it doesn't mean that
either you or I have to believe it.
Mar 14 '06 #3
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_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.
/* 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


--
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.
Mar 14 '06 #4
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.
Mar 14 '06 #5
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
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

--
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
Mar 14 '06 #6
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
Mar 14 '06 #7
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
Mar 14 '06 #8
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

Mar 15 '06 #9

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

19
by: Martin Pohlack | last post by:
Hi, I have a funtion which shall compute the amount for a later malloc. In this function I need the sizes of some struct members without having an instance or pointer of the struct. As...
33
by: Chris Fogelklou | last post by:
What is wrong with the above? Don't worry, I already know (learned my lesson last week.) It is for the benefit of our resident compiler guru who seems to think you need the cast. I thought it...
7
by: Zero | last post by:
If we have a structure like: struct something{ int *a; int b; }; We allocate mempry for a using malloc or calloc. The question is when we want to know the size of the structure,...
15
by: ak | last post by:
struct xy{ int x; int y; } _xy; size_of_xy(struct xy * a) { int len = sizeof a; printf( "\sizeof xy: %i\n", len ); }
10
by: Sean | last post by:
I have a struct that I wrote to test a protocol. The idea I had was to just declare the elements of the struct in the order in which they are sent and received as defined by the protocol. ...
10
by: Mark A. Odell | last post by:
Is there a way to obtain the size of a struct element based only upon its offset within the struct? I seem unable to figure out a way to do this (short of comparing every element's offset with...
7
by: sophia.agnes | last post by:
Dear all, why the following program is giving o/p as sizeof(struct emp) = 0 #include<stdio.h> #include<stdlib.h> struct emp
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.