struct named 0

[Mohd Hanafiah Abdullah]

Is the following code conformat to ANSI C?

typedef struct {
int a;
int b;
} doomdata;

int main(void)
{
int x;

x = (int)&((doomdat a*)0)->b;
printf("x=%d\n" , x);
return x;
}

The part,
(int)&((doomdat a*)0)->b;

is it conformant to ANSI C? What is it supposed to do?

Thanks for any tips.

Napi

--
http://www.axiomsol.com
http://www.cs.indiana.edu/hyplan/napi.html

[Michael Mair]

Mohd Hanafiah Abdullah wrote:

Is the following code conformat to ANSI C?

typedef struct {
int a;
int b;
} doomdata;

int main(void)
{
int x;

x = (int)&((doomdat a*)0)->b;
printf("x=%d\n" , x);
return x;
}

The part,
(int)&((doomdat a*)0)->b;

is it conformant to ANSI C? What is it supposed to do?

According to prior discussions, it is at least shady but
probably not conformant, depending on whether the address
0 is dereferenced or not.
This is a version of the offsetof macro from <stddef.h>:
offsetof(doomda ta,b)
gives you the byte offset of b in struct doomsdata, that means
if we have
struct doomdata d;
unsigned char *p = (unsigned char *)&d;
then the address of d.b is p+offsetof(doom data,b).
In contrast to offsetof which expands to an expression of
type size_t, the above will give you an int.

Use offsetof.
Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.

[S.Tobias]

Mohd Hanafiah Abdullah <na**@cs.indian a.edu> wrote:

typedef struct {
int a;
int b;
} doomdata; (int)&((doomdat a*)0)->b; is it conformant to ANSI C?

IMO no, because it doesn't point to any valid object, so
invokes UB.

Question to others:
Would this be correct?
(int)&((doomdat a*)0)->a;

--
Stan Tobias
mailx `echo si***@FamOuS.Be dBuG.pAlS.INVALID | sed s/[[:upper:]]//g`

[Malcolm]

"Mohd Hanafiah Abdullah" <na**@cs.indian a.edu> wrote

The part,
(int)&((doomdat a*)0)->b;

is it conformant to ANSI C? What is it supposed to do?

This is the offsetof() macro, which calculates the offset of a structure
member relative to the struct origin.
On most platforms it works, but it suffers a few problems on unusual
systems. For instance, if NULL is not all bits zero, or if there are trap
pointer representations , then the method won't work naturally. So I believe
that in C89 it is not required to work.

[Joona I Palaste]

Michael Mair <Mi**********@i nvalid.invalid> scribbled the following:

Mohd Hanafiah Abdullah wrote:

Is the following code conformat to ANSI C?

typedef struct {
int a;
int b;
} doomdata;

int main(void)
{
int x;

x = (int)&((doomdat a*)0)->b;
printf("x=%d\n" , x);
return x;
}

The part,
(int)&((doomdat a*)0)->b;

is it conformant to ANSI C? What is it supposed to do?

According to prior discussions, it is at least shady but
probably not conformant, depending on whether the address
0 is dereferenced or not.
This is a version of the offsetof macro from <stddef.h>:
offsetof(doomda ta,b)
gives you the byte offset of b in struct doomsdata, that means
if we have
struct doomdata d;
unsigned char *p = (unsigned char *)&d;
then the address of d.b is p+offsetof(doom data,b).
In contrast to offsetof which expands to an expression of
type size_t, the above will give you an int. Use offsetof.

To be more specific, offsetof may be defined as the version mentioned by
the OP, but it doesn't have to be. However, whatever offsetof is defined
as, it is guaranteed to always be legal and valid code for that
particular implementation. The version mentioned by the OP may or may
not be valid and legal code, depending on the implementation.

--
/-- Joona Palaste (pa*****@cc.hel sinki.fi) ------------- Finland --------\
\-------------------------------------------------------- rules! --------/
"The trouble with the French is they don't have a word for entrepreneur."
- George Bush

[Jack Klein]

On Sun, 28 Nov 2004 11:26:06 +0100, Michael Mair
<Mi**********@i nvalid.invalid> wrote in comp.lang.c:

Mohd Hanafiah Abdullah wrote:

Is the following code conformat to ANSI C?

typedef struct {
int a;
int b;
} doomdata;

int main(void)
{
int x;

x = (int)&((doomdat a*)0)->b;
printf("x=%d\n" , x);
return x;
}

The part,
(int)&((doomdat a*)0)->b;

is it conformant to ANSI C? What is it supposed to do?
According to prior discussions, it is at least shady but
probably not conformant, depending on whether the address
0 is dereferenced or not.

No it has undefined behavior, and has nothing to do with the "address
0", but with a null pointer. C is defined in terms of an abstract
machine, and in the abstract machine this expression dereferences a
null pointer.
This is a version of the offsetof macro from <stddef.h>:
offsetof(doomda ta,b)
gives you the byte offset of b in struct doomsdata, that means
if we have
struct doomdata d;
unsigned char *p = (unsigned char *)&d;
then the address of d.b is p+offsetof(doom data,b).
In contrast to offsetof which expands to an expression of
type size_t, the above will give you an int.

Use offsetof.
Yes, indeed. The implementation' s offsetof() macro might indeed
contain similar code, excepting the cast to int. But the
implementation is not constrained to follow the rules of the abstract
machine, only user programs are.
Cheers
Michael

--
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.l earn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[Jack Klein]

On 28 Nov 2004 10:41:21 GMT, "S.Tobias"
<si***@FamOuS.B edBuG.pAlS.INVA LID> wrote in comp.lang.c:

Mohd Hanafiah Abdullah <na**@cs.indian a.edu> wrote:

typedef struct {
int a;
int b;
} doomdata;

(int)&((doomdat a*)0)->b;

is it conformant to ANSI C?

IMO no, because it doesn't point to any valid object, so
invokes UB.

Question to others:
Would this be correct?
(int)&((doomdat a*)0)->a;

Technically it is still undefined behavior, as the semantics of the
expression dereference a null pointer.

--
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.l earn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[Jack Klein]

On Sun, 28 Nov 2004 10:53:23 -0000, "Malcolm"
<ma*****@55bank .freeserve.co.u k> wrote in comp.lang.c:

"Mohd Hanafiah Abdullah" <na**@cs.indian a.edu> wrote

The part,
(int)&((doomdat a*)0)->b;

is it conformant to ANSI C? What is it supposed to do?
This is the offsetof() macro, which calculates the offset of a structure
member relative to the struct origin.

No, it can't be the offsetof() macro. This expression specifically
yields an int, whereas the offsetof() macro yields a size_t. This
expression yields undefined behavior.
On most platforms it works, but it suffers a few problems on unusual
systems. For instance, if NULL is not all bits zero, or if there are trap
pointer representations , then the method won't work naturally. So I believe
that in C89 it is not required to work.

When will people get it through their heads that it makes not a whit
of difference whether all bits zero happens to be a representation of
a null pointer on a particular platform?

The correspondence between an integer constant expression evaluating
to 0 and a null pointer is exactly the same as quite a few other
constant expressions, that is something that is evaluated and
substituted at compile-time and has nothing to do with run-time
values.

The conversion of a quoted string to an array of '\0' terminated
values is a compile-time conversion.

The conversion of escape sequences like '\n' and '\t' to their single
character equivalents in string or character constants is a
compile-time conversion.

The conversion of an integer constant expression evaluating to 0, or
such an expression cast to the type pointer-to-void, to a null pointer
constant is a compile-time conversion, not a run-time one.

If the one and only representation for a null pointer in a particular
implementation is 0xDEADBEEF, and such a value is returned by a call
to fopen(), for example, a comparison of that value against NULL or 0
will still be true.

--
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.l earn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[Jack Klein]

On Sun, 28 Nov 2004 08:50:39 +0000 (UTC), na**@cs.indiana .edu (Mohd
Hanafiah Abdullah) wrote in comp.lang.c:

Is the following code conformat to ANSI C?

typedef struct {
int a;
int b;
} doomdata;

int main(void)
{
int x;

x = (int)&((doomdat a*)0)->b;
No, the line above invokes undefined behavior, because it dereferences
a null pointer.
printf("x=%d\n" , x);
return x;
}

The part,
(int)&((doomdat a*)0)->b;

is it conformant to ANSI C? What is it supposed to do?
No, it is most certainly not conforming. It might have been written
as an example, or it might have been written by someone who doesn't
know that the offsetof(struct _type,member_na me) macro defined in
<stddef.h> does the same thing in a conforming manner.
Thanks for any tips.

Napi

--
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.l earn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[Malcolm]

"Jack Klein" <ja*******@spam cop.net> wrote

The part,
(int)&((doomdat a*)0)->b;

is it conformant to ANSI C? What is it supposed to do?
This is the offsetof() macro, which calculates the offset of a structure
member relative to the struct origin.

No, it can't be the offsetof() macro. This expression specifically
yields an int, whereas the offsetof() macro yields a size_t. This
expression yields undefined behavior.

This is true. int is not guaranteed to be big enough to hold the offset of a
structure element (!).
When will people get it through their heads that it makes not a whit
of difference whether all bits zero happens to be a representation of
a null pointer on a particular platform?

Unfortunately it does make a difference.
For instance consider

char **list = calloc(N, sizeof(char *));

for(i=0;i<N;i++ )
if( someconditon() )
list[i] = malloc(10);

for(i=0;i<N;i++ )
free(list[i]);

Also consider if a null pointer is cast to an integral type, or if a pointer
derived by adding an offset to the null pointer is cast to an integer. This
cast is a simple bitwise conversion, so results will differ on a platform on
which NULL is not all bits zero.

However char *ptr = 0; will always set ptr to NULL, regardless of whether
the null pointer is all bits zero. Here you are correct.