offsetof

[Alejo]

Hello,

My implementation does not define offsetof, so I have designed a little
program that 'attempts' to find the relative position of a member in its
structure. It just does not work.

Could I get some pointers on what I am doing wrong (apart from being coding
so late at night).

#include <stdlib.h>
#include <stdio.h>

int main( void )
{
struct new
{
int a;
char b;
char c;
} x;

size_t num;

num = (size_t)((struct new *)&x.c - &x);

printf( "%u\n", num );

return EXIT_SUCCESS;
}

It always returns 0.

Thanks.

 

[Tom St Denis]

Hello,

My implementation does not define offsetof, so I have designed a little
program that 'attempts' to find the relative position of a member in its
structure. It just does not work.

Could I get some pointers on what I am doing wrong (apart from being coding
so late at night).

#include <stdlib.h>
#include <stdio.h>

int main( void )
{
struct new
{
int a;
char b;
char c;
} x;

size_t num;

num = (size_t)((struct new *)&x.c - &x);

printf( "%u\n", num );

return EXIT_SUCCESS;
}

It always returns 0.

Leave that aside. Why are you doing this anyways? The offset of
members is not a terribly portable quantity. So if this has todo with
loading/saving to a file [or memory buffer] you ought to rethink your
design.

As to the general question, maybe .c is the first element as packed by
the compiler. Try doing

x.c = 4;

and get the assembler code the compiler produces. My compiler [gcc
3.3.1 pre-release] produces

main:
pushl %ebp
movl %esp, %ebp
subl $8, %esp
andl $-16, %esp
movb $0, x+5
xorl %eax, %eax
leave
ret

Which seems to be at the end [not start].

Tom

 

[Alejo]

Sorry, I already realised where the mistake is. I should hve done a cast
(char *) instead of (struct new *). Like:

num = (size_t)((char *)&x.c - (char *)&x);

Well, thanks anyway.

 

[Marco de Boer]

Hello,

My implementation does not define offsetof, so I have designed a little
program that 'attempts' to find the relative position of a member in its
structure. It just does not work.

Could I get some pointers on what I am doing wrong (apart from being coding
so late at night).

#include <stdlib.h>
#include <stdio.h>

int main( void )
{
struct new
{
int a;
char b;
char c;
} x;

size_t num;

num = (size_t)((struct new *)&x.c - &x);

printf( "%u\n", num );

return EXIT_SUCCESS;
}

It always returns 0.

Thanks.

Hi,

Both(x.c and x) are interpreted as struct new *.
And the difference is less than one struct new: so 0.
This one is working:
num=(size_t)(&x.c-(char*)&x);

Marco

 

[Christian Bau]

Hello,

First, I will _not_ send emails, no matter how much you request them. I
will send emails to you if I intend you to read something that I don't
want the whole world to read, but if I post to the newsgroup then there
is no point in sending an email. You post here, you read here.

My implementation does not define offsetof, so I have designed a little
program that 'attempts' to find the relative position of a member in its
structure. It just does not work.

Could I get some pointers on what I am doing wrong (apart from being coding
so late at night).

#include <stdlib.h>
#include <stdio.h>

int main( void )
{
struct new
{
int a;
char b;
char c;
} x;

size_t num;

num = (size_t)((struct new *)&x.c - &x);

printf( "%u\n", num );

return EXIT_SUCCESS;
}

It always returns 0.

Not suprisingly. If you had an array

struct new array [100];

how many bytes are &array [0] and &array [1] apart? What is the
difference (&array [1]) - (&array [0])? If two pointers p and q are x
byte apart, how does the compiler calculate p - q?

 

[Jack Klein]

Hello,

My implementation does not define offsetof, so I have designed a little
program that 'attempts' to find the relative position of a member in its
structure. It just does not work.

Then you shouldn't be posting to comp.lang.c because whatever you
have, it is not a C compiler.

Or perhaps you have neglected to include <stddef.h>?

Understand that C provides for free-standing implementations, for
embedded systems and such, which are not required to provide even one
single function from the standard library, but they are still required
to provide the macros defined in <stddef.h>.

If what you have does not provide a working offsetof() macro in
<stddef.h>, it is literally not a C compiler.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq

 

[Jim]

Hello,

My implementation does not define offsetof, so I have designed a little
program that 'attempts' to find the relative position of a member in its
structure. It just does not work.

Could I get some pointers on what I am doing wrong (apart from being coding
so late at night).

#include <stdlib.h>
#include <stdio.h>

int main( void )
{
struct new
{
int a;
char b;
char c;
} x;

size_t num;

num = (size_t)((struct new *)&x.c - &x);

printf( "%u\n", num );

return EXIT_SUCCESS;
}

It always returns 0.

Leave that aside. Why are you doing this anyways? The offset of
members is not a terribly portable quantity. So if this has todo with
loading/saving to a file [or memory buffer] you ought to rethink your
design.

As to the general question, maybe .c is the first element as packed by
the compiler. Try doing

x.c = 4;

and get the assembler code the compiler produces. My compiler [gcc
3.3.1 pre-release] produces

main:
pushl %ebp
movl %esp, %ebp
subl $8, %esp
andl $-16, %esp
movb $0, x+5
xorl %eax, %eax
leave
ret

Which seems to be at the end [not start].

If your compiler generates that for x.c = 4, then it is wrong.

Jim

 

[Richard Bos]

As to the general question, maybe .c is the first element as packed by
the compiler.

Or maybe not, since it isn't allowed to shuffle elements this way. The
first element of a struct new in memory _must_ be a. There _cannot_ be
any padding before a. Hence, offsetof(struct new, a) must be 0, and
offsetof(struct new, c) is not allowed to be. Moreover, offsetof(struct
new, a) < offsetof(struct new, b) < offsetof(struct new, c).

Richard

 

[Arthur J. O'Dwyer]

Then you shouldn't be posting to comp.lang.c because whatever you
have, it is not a C compiler.

I thought offsetof() was new in C99. Am I mistaken?

-Arthur

 

[Hallvard B Furuseth]

I thought offsetof() was new in C99. Am I mistaken?

Yes. It's in ANSI C <stddef.h>.

 

[Robert W Hand]

I thought offsetof() was new in C99. Am I mistaken?

It is in my copy of ANSI/ISO 9899-1990, copyright 1990. It is defined
in stddef.h.

Best wishes,

Bob

 

[Jack Klein]

My implementation does not define offsetof [...]

#define offsetof(type,memb) ((size_t)&((type *)0)->memb)

Undefined behavior, dereferencing a null pointer.

The proper solution is to get a real C compiler.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq

 

[Sven Gohlke,,,]

My implementation does not define offsetof [...]

#define offsetof(type,memb) ((size_t)&((type *)0)->memb)

Undefined behavior, dereferencing a null pointer.

Thats the way most libraries implement offsetof, it works because it is a
constant expression which will be calculated at compile time. Of cause, a
more logical way would be

#define offsetof(type,memb) ((char *)&((type *)0)->memb-(char *) 0)

because offsetof should returm an offset_t not a size_t (but that violates
the standard).

The proper solution is to get a real C compiler.

An ANSI-C compiler should be sufficient, offsetof is part of the standard
library.

 

[Dan Pop]

My implementation does not define offsetof [...]

#define offsetof(type,memb) ((size_t)&((type *)0)->memb)

Undefined behavior, dereferencing a null pointer.

The proper solution is to get a real C compiler.

All the real C compilers I have ever used define offsetof in a similar
way. There is nothing preventing a C compiler from making undefined
behaviour work.

Dan

 

[Joona I Palaste]

My implementation does not define offsetof [...]

#define offsetof(type,memb) ((size_t)&((type *)0)->memb)

Undefined behavior, dereferencing a null pointer.

Thats the way most libraries implement offsetof, it works because it is a
constant expression which will be calculated at compile time. Of cause, a
more logical way would be

#define offsetof(type,memb) ((char *)&((type *)0)->memb-(char *) 0)

because offsetof should returm an offset_t not a size_t (but that violates
the standard).

I think you're missing something here. The ANSI C standard does not
specify that the expression &((type *)0)->memb should be calculated all
at compile time. The people who wrote those libraries are usually the
same ones who wrote the compilers, so they can benefit from the
knowledge that on *THEIR* compiler, it's evaluated all at compile time,
so it's safe. But this doesn't imply that it would be safe on any other
compiler.

An ANSI-C compiler should be sufficient, offsetof is part of the standard
library.

The behaviour of offsetof is standard, but any particular implementation
of it is not. Jack Klein's point was that any ANSI C compiler is
required to provide *an* implementation of offsetof, but there is no
particular implementation of offsetof that the compilers would be
required to choose.
In other words: Leave offsetof for the library to implement. If you try
implementing it yourself, you'll run into undefined behaviour.

--
/-- Joona Palaste ([email protected]) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"I will never display my bum in public again."
- Homer Simpson

 

[Jack Klein]

My implementation does not define offsetof [...]

#define offsetof(type,memb) ((size_t)&((type *)0)->memb)

Undefined behavior, dereferencing a null pointer.

The proper solution is to get a real C compiler.

All the real C compilers I have ever used define offsetof in a similar
way. There is nothing preventing a C compiler from making undefined
behaviour work.

Dan

Of course not, in many instances a compiler is required to make
undefined behavior work. For example, how fopen() actually
establishes a connection to some type of physical device is undefined,
but a compiler makes it work.

One can't implement the entire standard C library without doing some
things that are undefined according to the standard. The
implementation and its library are not bound by the same constraints
as conforming programs.

The point is the OP says his compiler lacks a definition of the
offsetof() macro. Even free-standing implementations, which are not
required to provide even one single standard library function, are
required to provide the offsetof() and other macros in stddef.h, among
other things.

So either the OP is mistaken, or whatever it is he is using is not a C
compiler, in which case he's off-topic here.

The C language does not define an implementation that does not provide
a workable offsetof() macro in stddef.h.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq

 

[Dan Pop]

The point is the OP says his compiler lacks a definition of the
offsetof() macro. Even free-standing implementations, which are not
required to provide even one single standard library function, are
required to provide the offsetof() and other macros in stddef.h, among
other things.

So either the OP is mistaken, or whatever it is he is using is not a C
compiler, in which case he's off-topic here.

If we adopt a rigid black and white position, then there is probably no C
compiler out there, they're complex enough programs to have bugs of one
kind of another.

Furthermore, this group is still dealing with pre-ANSI C issues and no
pre-ANSI C compiler can even hope to qualify as a conforming C compiler.

The C language does not define an implementation that does not provide
a workable offsetof() macro in stddef.h.

This doesn't prevent the existence of implementations that don't do that.
Either because they predate the C standard or because they did not
attempt to be conforming implementations (for one reason or another).

Therefore, questions about how to implement the functionality of offsetof
are topical in this newsgroup, even if the most portable solution invokes
undefined behaviour.

But I still suspect that the OP simply failed to include <stddef.h> and
expected offsetof to be available as some kind of compiler or preprocessor
built-in functionality.

Dan

 

[Emmanuel Delahaye]

I thought offsetof() was new in C99. Am I mistaken?

Yes. It came with C90 in <stddef.h>

 

[Dan Pop]

Yes. It came with C90 in <stddef.h>

Nope, it came with C89.

Dan

 

[Shill]

Nope, it came with C89.

http://gcc.gnu.org/onlinedocs/gcc-3.3/gcc/Standards.html

The original ANSI C standard (X3.159-1989) was ratified
in 1989 and published in 1990. This standard was ratified
as an ISO standard (ISO/IEC 9899:1990) later in 1990.
There were no technical differences between these
publications, although the sections of the ANSI standard
were renumbered and became clauses in the ISO standard.
This standard, in both its forms, is commonly known as C89,
or occasionally as C90, from the dates of ratification.

C89 and C90 are synonymous.