Operand of postfix operator ->

[Rajesh S R]

Consider the following code:
int main()
{
struct name
{
long a;
int b;
long c;
}s={3,4,5},*p;
p=&s;

printf("%d",*(int *)((char *)p+(unsigned int)&(((struct name*)0)-

b)));

return 0;
}

Is the expression (unsigned int)&(((struct name*)0)->b) valid as per
C99?

That is,
Can an operand of postfix operator -> be a null pointer?

Please clarify.

Thanks in advance for the reply.

 

[Richard Tobin]

Is the expression (unsigned int)&(((struct name*)0)->b) valid as per
C99?
No.

That is,
Can an operand of postfix operator -> be a null pointer?

-> is not a postfix operator. It has two operands and appears between
them, so it's an infix operator.

-- Richard

 

[Chris Dollin]

Consider the following code:
int main()
{
struct name
{
long a;
int b;
long c;
}s={3,4,5},*p;
p=&s;

Were we pairing, I'd not let that stay like that. Oh no.

printf("%d",*(int *)((char *)p+(unsigned int)&(((struct name*)0)-

At this point I'd ask you what on earth you were trying to do.
I wouldn't much care whether it was legal-by-the-Standard; I'd
care that it was indecently obscure.

return 0;
}

Is the expression (unsigned int)&(((struct name*)0)->b) valid as per
C99?

I don't think so.

That is,
Can an operand of postfix operator -> be a null pointer?

Yes, it can be. The result is undefined. So don't do that.

(Your clarification asks a different question from your original.)

 

[Richard Tobin]

printf("%d",*(int *)((char *)p+(unsigned int)&(((struct name*)0)-

[/QUOTE]

At this point I'd ask you what on earth you were trying to do.

Presumably he's trying to implement sizeof(), as apparently everyone
in India is doing these days. I assume he's on the same course as all
the others asking similar questions.

-- Richard

 

[Stephen Sprunk]

printf("%d",*(int *)((char *)p+(unsigned int)&(((struct name*)0)- ....
Is the expression (unsigned int)&(((struct name*)0)->b) valid as per
C99?

No. What you're seeing is one rather common implementation of offsetof(),
but it's officially UB for _you_ to use this construct unless you're writing
the implementation itself. Use offsetof() and you don't have to worry about
those systems where it doesn't actually work.

That is,
Can an operand of postfix operator -> be a null pointer?

It's an infix operator, and the first operand must be a pointer to an
object. Since a null pointer constant does not point to an object by
definition, it's UB.

S

 

[Rajesh S R]

Thanks for ur reply.

-> is not a postfix operator. It has two operands and appears between
them, so it's an infix operator.

But C standards categorises an -> as postfix operator( C99 6.5.2 ) .
So what's wrong in stating it as a postfix operator?
Even C99 calls it that way!

 

[Richard Tobin]

-> is not a postfix operator. It has two operands and appears between
them, so it's an infix operator.

[/QUOTE]

But C standards categorises an -> as postfix operator( C99 6.5.2 ) .

You're right.

I can't imagine why they decided to misuse a well-defined term in that
way.

-- Richard

 

[Rajesh S R]

Thanks for your reply.

-> is not a postfix operator. It has two operands and appears between
them, so it's an infix operator.

(C99 6.5.2) categorises -> as postfix operator. So whats wrong in
calling it that way?

 

[Martin Ambuhl]

Consider the following code:
int main()
{
struct name
{
long a;
int b;
long c;
}s={3,4,5},*p;
p=&s;

printf("%d",*(int *)((char *)p+(unsigned int)&(((struct name*)0)-

return 0;
}

Is the expression (unsigned int)&(((struct name*)0)->b) valid as per
C99?

There are otherwise enough errors in your code to make "valid as per
C99" a sick joke. And this is the most perverse way I have ever seen of
spelling the expression "p->b".

That is,
Can an operand of postfix operator -> be a null pointer?

-> is not a postfix operator. Strangely, your code claims it isn't a
token at all.

 

[Army1987]

Consider the following code:
int main()
{
struct name
{
long a;
int b;
long c;
}s={3,4,5},*p;
p=&s;

printf("%d",*(int *)((char *)p+(unsigned int)&(((struct name*)0)-

You've managed to beat my lecturer (and the book he copied from) in the
contest of the ugliest line of code ever:
http://groups.google.com/group/comp.lang.c/msg/[email protected]

return 0;
}

Is the expression (unsigned int)&(((struct name*)0)->b) valid as per
C99?

What the hell are you trying to do?

 

[Keith Thompson]

But C standards categorises an -> as postfix operator( C99 6.5.2 ) .

You're right.

I can't imagine why they decided to misuse a well-defined term in that
way.[/QUOTE]

Probably because the thing on the right hand side isn't really an
operand; it must be the name of a member of the appropriate structure
or union. In s->m, s must be an expression (specifically a
postfix-expression), but m *cannot* be an expression.

The way I sometimes think of it (which is not the way the standard
expresses it) is that a declaration like:

struct foo { int x; int y; };

implicitly creates *four* postfix operators: ".x" and ".y", which can
be applied to expresions of type struct foo, and "->x" and "->y",
which can be applied to expressions of type struct foo*.

 

[Richard Tobin]

I can't imagine why they decided to misuse a well-defined term in that
way.

[/QUOTE]

Probably because the thing on the right hand side isn't really an
operand; it must be the name of a member of the appropriate structure
or union. In s->m, s must be an expression (specifically a
postfix-expression), but m *cannot* be an expression.

This argument would be a lot more plausible if they didn't also call
the array subscripting operator postfix. It's particular egregious in
that case as the subscripting operator is commutative!

I suppose they just considered that these operators are "accessors",
where the "main" operand is (usually) on the right.

-- Richard

 

[whyglinux]

Is the expression (unsigned int)&(((struct name*)0)->b) valid as per
C99?

That is,
Can an operand of postfix operator -> be a null pointer?

Yes, the expression is defined and the left operand of -> can be a
null pointer.

We all know that dereferencing a null pointer produces undefined
behavior, but if the -> operator is not evaluated, it will not.

One such example with defined behavior is: sizeof( ((struct name*)0)-

b ), another is your expression.

There exists a special rule in C99:

"If the operand (of the unary & operator) is the result of a unary *
operator, neither that operator nor the & operator is evaluated and
the result is as if both were omitted"

The expression &(((struct name*)0)->b) can be re-written as
&((*((struct name*)0)).b) and thus the above rule can be applied -
neither the & nor the * operator will be evaluated. No evaluation then
means no undefined behavior.

 

[Flash Gordon]

whyglinux wrote, On 25/04/07 05:55:

Yes, the expression is defined and the left operand of -> can be a
null pointer.

We all know that dereferencing a null pointer produces undefined
behavior, but if the -> operator is not evaluated, it will not.

I disagree, see below.

One such example with defined behavior is: sizeof( ((struct name*)0)-

There exists a special rule in C99:

"If the operand (of the unary & operator) is the result of a unary *
operator, neither that operator nor the & operator is evaluated and
the result is as if both were omitted"

The expression &(((struct name*)0)->b) can be re-written as
&((*((struct name*)0)).b) and thus the above rule can be applied -
neither the & nor the * operator will be evaluated. No evaluation then
means no undefined behavior.

The operand is not the result of a unary *, it is the result of
selecting an element of a struct *after* dereferencing the unary * to
find the relevant instance of the struct. Therefore that exception does
not apply.

There is also still the question "why not use the offsetof macro? that's
what it's there fore."

 

[whyglinux]

whyglinux wrote, On 25/04/07 05:55:




I disagree, see below.





The operand is not the result of a unary *, it is the result of
selecting an element of a struct *after* dereferencing the unary * to
find the relevant instance of the struct. Therefore that exception does
not apply.

There is also still the question "why not use the offsetof macro? that's
what it's there fore."

Yes, you are right - the operand is not the result of the unary *
operator and thus my cited rule can not be applied.

As other posters have already said: the expression (unsigned
int)&(((struct name*)0)->b) is undefined since dereferencing a null
pointer. For the reason, we should not write suchlike code. Instead we
should use the offsetof macro defined in <stddef.h> directly.

Thanks.

 

[Rajesh S R]

What the hell are you trying to do?

Nothing, This is not the code I contrived by myself!
I saw this code in a C Quiz site.
I suspected it to be a UB and at the same time I was not sure if it's
really one.
So I just want to get it confirmed before proclaiming to myself that
it is a UB!

I thank you all for your responses. Finally, my doubt is clear and
now, I am sure that it is a UB.

 

[Rajesh S R]

Consider the following code:
int main()
{
struct name
{
long a;
int b;
long c;}s={3,4,5},*p;

p=&s;

printf("%d",*(int *)((char *)p+(unsigned int)&(((struct name*)0)-


return 0;

}

Is the expression (unsigned int)&(((struct name*)0)->b) valid as per
C99?

That is,
Can an operand of postfix operator -> be a null pointer?

Please clarify.

Thanks in advance for the reply.

I thank all of you for your responses. Now a new question has popped
out of my mind. Let me clarify that I am very much aware that my
present question is not based on standards. Therfore one can not use
standards to give a reply. This question is about the implementation
and optimisation.

My question is:
Can the expression (unsigned int)&(((struct name*)0)->b) be evaluated
at translation time itself, so that no ru time error is produced?

The thing that prompted me to pose this question is that this program
runs successfully without causing any segmentation faults in DEV-CPP
compiler for Win-32. This makes me think that the above expression is
evaluated at translation time itself. Please clarify.

 

[Richard Tobin]

My question is:
Can the expression (unsigned int)&(((struct name*)0)->b) be evaluated
at translation time itself, so that no ru time error is produced?

*If* the expression were legal C, then one would expect it to be a
constant expression, just as &((&foo)->b) is when foo is a static struct
name. It would therefore be natural for the compiler to evaluate it
at compile time.

It's not legal C, but it would still be natural for a compiler that
accepted it to evaluate it at compile time.

-- Richard

 

[Flash Gordon]

Rajesh S R wrote, On 27/04/07 16:40:

out of my mind. Let me clarify that I am very much aware that my
present question is not based on standards. Therfore one can not use
standards to give a reply. This question is about the implementation
and optimisation.

My question is:
Can the expression (unsigned int)&(((struct name*)0)->b) be evaluated
at translation time itself, so that no ru time error is produced?

As it is undefined behaviour the compiler can treat it as a run time
error, compile time error, or anything else it wants. It does not even
have to treat it the same each time it sees it.

The thing that prompted me to pose this question is that this program
runs successfully without causing any segmentation faults in DEV-CPP
compiler for Win-32. This makes me think that the above expression is
evaluated at translation time itself. Please clarify.

It is evaluated or not whenever the compiler or compiled program happens
to do it.