offsetof() macro

[Simon Morgan]

Hi,

Can somebody please help me grok the offsetof() macro?

I've found an explanation on
http://www.embedded.com/shared/print...cleID=18312031
but I'm afraid it still doesn't make sense to me.

The sticking point seems to be:

((s *)0) takes the integer zero and casts it as a pointer to s.

To my untrained eye that would basically result in a null pointer. Does
this expression result in some special behaviour or am I missing
something?

Thanks.

Simon

--
"Being a social outcast helps you stay concentrated on the really important
things, like thinking and hacking." - Eric S. Raymond

[Keith Thompson]

DevarajA <[e-mail]> writes:
[...]

Another thing.. looking into stddef.h I've seen that for C, NULL it is
defined as ((void*)0). The standard specifies that plain 0 is already
a null pointer constant. So why that cast? Maybe this is the last
stupid question for today :-)

No, looking into the stddef.h header for your implementation tells you
how your implementation defines NULL. Another implementation could
define it as 0.

The standard says that a null pointer constant is "An integer constant
expression with the value 0, or such an expression cast to type void *",
and that NULL is a macro that "expands to an implementation-defined
null pointer constant".

One advantage of defining NULL as ((void*)0) rather than as 0 is that
it can catch some errors. A constant 0, though it's a null pointer
constant, can also be used in a non-pointer context; ((void*)0)
cannot. For example, I've seen code that incorrectly uses NULL to
denote a null character:
char s[50];
s[0] = NULL;
If NULL is defined as 0, this won't be diagnosed. If it's defined as
((void*)0), it will be.

Please ignore the remainder of this message.

There's actually some doubt about whether ((void*)0) is a legal
definition for NULL. The standard says that a constant 0 cast to
void* is a null pointer constant. It doesn't say that a constant 0
cast to void* *and enclosed in parentheses* is a null pointer
constant. C99 6.5.1 says a parenthesized expression "is an lvalue, a
function designator, or a void expression if the unparenthesized
expression is, respectively, an lvalue, a function designator, or a
void expression"; it doesn't say that a parenthesized expression is a
null pointer constant if the unparenthesized expression is a null
pointer constant.

This is nothing more than a minor glitch in the wording of the
standard, of no real significance either to programmers or to
implementers.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Flash Gordon]

DevarajA wrote:

<snip>

Another thing.. looking into stddef.h I've seen that for C, NULL it is
defined as ((void*)0). The standard specifies that plain 0 is already a
null pointer constant. So why that cast? Maybe this is the last stupid
question for today :-)

The C standard allows the implementation to include the case, and the
reason that some implementations do so is to prevent you from using NULL
in an integer context. So on your implementation the following are all
constraint violations because pointers are not automatically converted
to numbers:

char c = NULL;
int i = NULL;
float f = NULL;
double d = NULL;

However, on an implementation where NULL is defined as plain 0 (which
the standard allows) all of the above are legal even though to a human
reader they don't make sense.

One reason people do mistakenly assign NULL to char variables (or
elements of char arrays) is because the ASCII character set (which C
does not mandate) calls character '\0' NUL and the C standard I believe
calls it a null character, so it is easy to get it confused with NULL.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.

[Walter Roberson]

In article <q9************ *************** *****@4ax.com>,
Irrwahn Grausewitz <ir*******@free net.de> wrote:

Depends on the implementation, yours happen to use the above
definition, another might define NULL as (0) or even
((void *)('9'-'4'-'5')).

That would only be equivilent to 0 in the rather unusual case
that the representation of the digits started from 0 instead of
(e.g.) ASCII's 48.

Perhaps you meant ((void *)('9'-'4'-5))

--
'The short version of what Walter said is "You have asked a question
which has no useful answer, please reconsider the nature of the
problem you wish to solve".' -- Tony Mantler

[Kenneth Brody]

Irrwahn Grausewitz wrote:

DevarajA <[e-mail]> wrote:

[...]

Maybe this is the last stupid
question for today :-)

There are no stupid questions, only stupid answers. :-)

You've obviously never hung around ASR and ATSR, have you? They'll give
you plently of "stupid question" examples. :-)

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer .h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:Th***** ********@gmail. com>

[Kenneth Brody]

DevarajA wrote:
[...]

Another thing.. looking into stddef.h I've seen that for C, NULL it is
defined as ((void*)0). The standard specifies that plain 0 is already a
null pointer constant. So why that cast? Maybe this is the last stupid
question for today :-)

Probably to explicitly make it a pointer.

That, and to give warnings when someone does:

char *pt;
...
while ( *pt != NULL )
...

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer .h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:Th***** ********@gmail. com>

[Irrwahn Grausewitz]

ro******@ibd.nr c-cnrc.gc.ca (Walter Roberson) wrote:

In article <q9************ *************** *****@4ax.com>,
Irrwahn Grausewitz <ir*******@free net.de> wrote:

Depends on the implementation, yours happen to use the above
definition, another might define NULL as (0) or even
((void *)('9'-'4'-'5')).

That would only be equivilent to 0 in the rather unusual case
that the representation of the digits started from 0 instead of
(e.g.) ASCII's 48.

Perhaps you meant ((void *)('9'-'4'-5))

Umm... something like that... brain fart on my side...
me dumba, he he. :)

Thanks for pointing out & best regards
--
Irrwahn Grausewitz (ir*******@free net.de)
welcome to clc : http://www.ungerhu.com/jxh/clc.welcome.txt
clc faq-list : http://www.faqs.org/faqs/C-faq/faq/
clc frequent answers: http://benpfaff.org/writings/clc.

[Simon Morgan]

On Thu, 08 Sep 2005 15:11:27 +0000, Simon Morgan wrote:

Can somebody please help me grok the offsetof() macro?

Thank you all for the excellent explanations, they were most helpful.

--
"Being a social outcast helps you stay concentrated on the really important
things, like thinking and hacking." - Eric S. Raymond

[Tim Rentsch]

Keith Thompson <ks***@mib.or g> writes:

DevarajA <[e-mail]> writes:

Keith Thompson ha scritto: [...]

A "null pointer" and a "null pointer constant" are two different
things. A null pointer constant is a construct that can appear in
C source code. A null pointer is a pointer value that can occur
during execution time. An integer constant 0 is a valid null
pointer constant. If you assign a null pointer constant to a
pointer object, that object's value at execution time will be a
null pointer. The execution-time representation of a null pointer
may or may not be all-bits-zero. (If a null pointer has a
representation other than all-bits-zero, it's up to the compiler to
do whatever conversion might be necessary.) The macro NULL expands
to a null pointer constant. You cannot legally redefine NULL
yourself. Your compiler might let you get away with it, but
there's absolutely no reason to do so.

Then using NULL is the same as using 0? So why in C many people use
NULL? Is that to avoid portability problems (in the case of a weird
non-standard implementation that has the null ptr const !=0)?

The advantage of using NULL is documentation. It makes it obvious
that what's intended is a pointer value, not an integer value.

For example:

a = 0;
b = 0.0;
c = '\0';
d = NULL;

You can tell even without looking at the declarations (assuming a sane
programmer) that a is an integer, b is a floating-point variable, c is
a character, and d is a pointer.

A complaint I have about NULL is that NULL isn't guaranteed to be
a pointer. Supplying NULL as a trailing argument (corresponding
to a post-ellipsis parameter), for example, isn't guaranteed to
pass a pointer rather than an int 0. It would be nice if the
Standard were changed to fix this.
[snip] The current confusing situation is, I think, a remnant of the early
days of C when it was assumed that a null pointer *was* all-bits-zero,
and even non-zero integer constants were commonly used as pointers.

Perhaps partly, but there's another factor that may play a larger
role here. C deliberately proclaimed null pointers as zero and
non-null pointers as non-zero, so that they would work nicely
with if's and while's. People who learned C later seem to like
explicit comparisons (whether to NULL or 0); "old timers" are
more used to seeing things like

if(p) ...
if(!p) ...

and may even prefer them. For these forms, it's convenient to
think of null pointers as being all-bits-zero, even if in the
back of the mind it's known not to always be true.

[Tim Rentsch]

Keith Thompson <ks***@mib.or g> writes:

There's actually some doubt about whether ((void*)0) is a legal
definition for NULL. The standard says that a constant 0 cast to
void* is a null pointer constant. It doesn't say that a constant 0
cast to void* *and enclosed in parentheses* is a null pointer
constant. C99 6.5.1 says a parenthesized expression "is an lvalue, a
function designator, or a void expression if the unparenthesized
expression is, respectively, an lvalue, a function designator, or a
void expression"; it doesn't say that a parenthesized expression is a
null pointer constant if the unparenthesized expression is a null
pointer constant.

Whatever NULL is defined as seems like it must be a null pointer
constant, by definition. Per 7.17 p3, NULL "expands to an
implementation-defined null pointer constant". So even if we had

#define NULL the rain in Spain falls mainly on the plain

it would be (defined by the implementation as) a null pointer
constant. It's just up to the other parts of the implementation
to insure that it behaves as one.

Is it true that, except for function pointers, it's unnecessary
to have '(void*) <constant-zero-expression>' be defined as a
null pointer constant?

[Irrwahn Grausewitz]

Tim Rentsch <tx*@alumnus.ca ltech.edu> wrote:

Whatever NULL is defined as seems like it must be a null pointer
constant, by definition. Per 7.17 p3, NULL "expands to an
implementati on-defined null pointer constant". So even if we had

#define NULL the rain in Spain falls mainly on the plain

it would be (defined by the implementation as) a null pointer
constant. It's just up to the other parts of the implementation
to insure that it behaves as one.
IOW: the implementation has to take care that
the rain in Spain falls mainly on the plain
is treated as an integer constant expression with the value 0,
possibly cast to void * (see below). Ugly, but IMHO feasible.
But ugly. Did I already mention ugly?
Is it true that, except for function pointers, it's unnecessary
to have '(void*) <constant-zero-expression>' be defined as a
null pointer constant?

In which aspect are function pointers different? Consider:

ISO/IEC 9899:1999 (E)
6.3.2.3p3
An integer constant expression with the value 0, or such an
expression cast to type void *, is called a null pointer constant.
If a null pointer constant is converted to a pointer type, the
resulting pointer, called a null pointer, is guaranteed to compare
unequal to a pointer to any object or function.

6.5.16.1
1 One of the following shall hold:
[...]
— the left operand is a pointer and the right is a null pointer
constant
[...]
2 In simple assignment (=), the value of the right operand is
converted to the type of the assignment expression and replaces the
value stored in the object designated by the left operand.

Did I miss anything important?

Best Regards
--
Irrwahn Grausewitz (ir*******@free net.de)
welcome to clc : http://www.ungerhu.com/jxh/clc.welcome.txt
clc faq-list : http://www.faqs.org/faqs/C-faq/faq/
clc frequent answers: http://benpfaff.org/writings/clc