offsetof
Alejo
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.
--
Alejo
Tom St Denis
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
(char *) instead of (struct new *). Like:
num = (size_t)((char *)&x.c - (char *)&x);
Well, thanks anyway.
Marco de Boer
news:fKGQa.16616$KF1.303303@amstwist00...
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
wrote:
> 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.
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?
Emmanuel Delahaye
> My implementation does not define offsetof, so I have designed a little
Hard to believe. Have you included <stddef.h> ?
--
-ed- emdelY...@noos.fr [remove YOURBRA before answering me]
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
<blank line>
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
Jack Klein
comp.lang.c:
> 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
wrote:
If your compiler generates that for x.c = 4, then it is wrong.
Jim
Robert Wessel
> (...)
> > struct new
> > {
> > int a;
> > char b;
> > char c;
> > } x;
> >
>
> 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
>
*sigh*
The C compiler does not have license to reorder members of a
structure.
c89, 6.5.2.1: "...Within a structure object, the [members] have
addresses that increase in the order in which they are declared. ..."
Richard Bos
> Alejo wrote:
> > struct new
> > {
> > int a;
> > char b;
> > char c;
> > } x;
> 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
On Tue, 15 Jul 2003, Jack Klein wrote:
>
> On Tue, 15 Jul 2003 01:09:28 +0200, Alejo wrote in comp.lang.c:
> >
> > 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.
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>.
--
Hallvard
Shill
#define offsetof(type,memb) ((size_t)&((type *)0)->memb)
Robert W Hand
<a...@andrew.cmu.edu> wrote:
>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
in comp.lang.c:
> > 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.
Dan Pop
>On Tue, 15 Jul 2003 16:27:38 +0200, Shill <nob...@example.com> wrote
>in comp.lang.c:
>
>> > 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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan...@ifh.de
Sven Gohlke,,,
> On Tue, 15 Jul 2003 16:27:38 +0200, Shill <nob...@example.com> wrote
> in comp.lang.c:
>
>> > 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.
--
Best Regards
Sven
Joona I Palaste
> Jack Klein wrote:
>> On Tue, 15 Jul 2003 16:27:38 +0200, Shill <nob...@example.com> wrote
>> in comp.lang.c:
>>
>>> > 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.
>> The proper solution is to get a real C 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 (pal...@cc.helsinki.fi) ---------------------------\
| 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
Dan Pop
And my point is that
#define offsetof(type, memb) ((size_t)&((type *)0)->memb)
can be used on *any* compiler where it works, in the absence of an
"official" definition provided by the implementor.
In other words, it is OK to put it in a <stddef.h> that doesn't already
have it, *after* testing it on that compiler. It's not OK to put it in
your application's header, if the application is supposed to be portable.
Dan Pop
>My implementation does not define offsetof...
Have you tried including <stddef.h>?
Jack Klein
comp.lang.c:
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.
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.
Emmanuel Delahaye
> I thought offsetof() was new in C99. Am I mistaken?
Yes. It came with C90 in <stddef.h>
Dan Pop
>In 'comp.lang.c', "Arthur J. O'Dwyer" <a...@andrew.cmu.edu> wrote:
>
>> I thought offsetof() was new in C99. Am I mistaken?
>
>Yes. It came with C90 in <stddef.h>
Nope, it came with C89.
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.
Emmanuel Delahaye
> Nope, it came with C89.
C89 is ANSI. It doesn't exist outside the USA ;-)
Dan Pop
>In 'comp.lang.c', Dan...@cern.ch (Dan Pop) wrote:
>
>> Nope, it came with C89.
>
>C89 is ANSI. It doesn't exist outside the USA ;-)
Does this mean that C90 ceased to exist outside the USA when it was
adopted as an ANSI standard? ;-)
Dan Pop
Nope, they aren't. They refer to two different documents. Even if the
technical contents is the same, the section renumbering is a pain in
the ass when you have to post references. All the compilers that used
to produce standard references in their diagnostics used the C89
numbering (probably because POSIX requires C89 conformance).
And C89 predates C90 ;-)