Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Can *common* struct-members of 2 different struct-types, that are thesame for the first common members, be accessed via pointer cast to either struct-type?

Reply
Thread Tools

Can *common* struct-members of 2 different struct-types, that are thesame for the first common members, be accessed via pointer cast to either struct-type?

 
 
John Reye
Guest
Posts: n/a
 
      05-03-2012
On May 3, 6:25*pm, John Reye wrote:
> In fact...
>
> then any use of pointers at all would fail.
> char a;
> char *p;
>
> a = 1;
> *p = 2;
> printf("%d", a);
>
> This will never print 1, unless the compiler is buggy.


Correction in 2nd line of code:
char *p = &a;
 
Reply With Quote
 
 
 
 
Nobody
Guest
Posts: n/a
 
      05-03-2012
On Thu, 03 May 2012 09:20:24 -0700, John Reye wrote:

>> * * * * tmp.c1 = 1;
>> * * * * printf("%d\n", ((struct b*)&tmp)->c1);
>>
>> An implementation is not required to notice that the printf() is
>> referring to the same object as the assignment statement.

>
> Hmmm... I think that would be one heck of a rubbish compiler (or more
> precisely *optimizing* compiler)!
>
> If the standard allows that kind of stuff, then it simply is not
> bullet-proof enough.
>
> Because tmp occurs in both lines. Every compiler should notice that!


The compiler is free to lose track of that information during
optimisation, and may well do so.

> Why? Because it's an optimizer BUG.


A bug is a failure to behave as documented, not a failure to behave
according to the intuition of some guy on usenet.

If it were otherwise, all compilers would have bugs, and those bugs would
be impossible to fix, as different people's intutions are different and
often contradictory.

> Why?
> Because any simple compiler, that does not optimize... get's it right!
> And if any simple compiler get's it right, then any optimization must
> guarantee to get it right as well.


The behaviour of a "simple" compiler does not form a part of the standard.

> I mean: if the C standard allows one to create optimizers that result
> in such ... ummm... surprises (read: "rubbish"), then the standard is
> faulty in my eyes.


Whether or not it is faulty "in your eyes" is irrelevant. The standard
is what it is.

The standard explicitly and intentionally facilitates optimisation, rather
than forcing the majority of real-world code to be suboptimal for the sake
of pathological cases. This is also why "const" and "volatile" were added
to C89 and "restrict" to C99, in spite of being completely unnecessary for
"simple" (i.e. non-optimising) compilers.

 
Reply With Quote
 
 
 
 
John Reye
Guest
Posts: n/a
 
      05-03-2012
On May 3, 8:14*pm, Nobody wrote:
> The compiler is free to lose track of that information during
> optimisation, and may well do so.


char a;
char *p = &a;

a = 1;
*p = 2;
printf("%d\n", a);

Does the C standard guarantee, that the value 2 will get printed in
the above code??
Thanks.
 
Reply With Quote
 
Jens Gustedt
Guest
Posts: n/a
 
      05-03-2012
Am 05/03/2012 08:45 PM, schrieb John Reye:
> On May 3, 8:14 pm, Nobody wrote:
>> The compiler is free to lose track of that information during
>> optimisation, and may well do so.

>
> char a;
> char *p = &a;
>
> a = 1;
> *p = 2;
> printf("%d\n", a);
>
> Does the C standard guarantee, that the value 2 will get printed in
> the above code??


no

for that you'd have to declare them

char volatile a;
char volatile *p = &a;

Jens



 
Reply With Quote
 
John Reye
Guest
Posts: n/a
 
      05-03-2012
On May 3, 9:05*pm, Jens Gustedt wrote:
> > char a;
> > char *p = &a;

>
> > a = 1;
> > *p = 2;
> > printf("%d\n", a);

>
> > Does the C standard guarantee, that the value 2 will get printed in
> > the above code??

>
> no
>
> for that you'd have to declare them
>
> char volatile a;
> char volatile *p = &a;
>
> Jens



Thanks!!!
So it would seem that good C coders sprinkle a lot of volatile.
 
Reply With Quote
 
John Reye
Guest
Posts: n/a
 
      05-03-2012
Assume no volatile:

char a;
char *p = &a;

Does the C standard guarantee that the following will print 2? ->

a = 1, *p = 2, printf("%d\n", a);

Thanks.
 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      05-03-2012
On 05/03/2012 03:05 PM, Jens Gustedt wrote:
> Am 05/03/2012 08:45 PM, schrieb John Reye:
>> On May 3, 8:14 pm, Nobody wrote:
>>> The compiler is free to lose track of that information during
>>> optimisation, and may well do so.

>>
>> char a;
>> char *p = &a;
>>
>> a = 1;
>> *p = 2;
>> printf("%d\n", a);
>>
>> Does the C standard guarantee, that the value 2 will get printed in
>> the above code??

>
> no


Why not? In the abstract machine those statements must be executed in
sequence. There's a sequence point at the end of each statement, which
means that side effects such as the change in value of a in the second
statement, must be complete by the time the value of 'a' is read by the
third statement.

> for that you'd have to declare them
>
> char volatile a;
> char volatile *p = &a;


Why should that be necessary?
 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      05-03-2012
On 05/03/2012 02:45 PM, John Reye wrote:
> On May 3, 8:14 pm, Nobody wrote:
>> The compiler is free to lose track of that information during
>> optimisation, and may well do so.

>
> char a;
> char *p = &a;
>
> a = 1;
> *p = 2;
> printf("%d\n", a);
>
> Does the C standard guarantee, that the value 2 will get printed in
> the above code??


Yes.

The key point is that *p and a have the same type, so there's no
violation of the anti-aliasing rules. There's also a special exemption
in those rules for character types, so the behavior would remain
well-defined even if 'a' had the type 'int'.
 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      05-03-2012
On 05/03/2012 12:25 PM, John Reye wrote:
> In fact...
>
> then any use of pointers at all would fail.
> char a;
> char *p;
>
> a = 1;
> *p = 2;
> printf("%d", a);


How do you reach that conclusion? That use of pointers doesn't violate
the anti-aliasing rules.
 
Reply With Quote
 
John Reye
Guest
Posts: n/a
 
      05-03-2012
On May 3, 9:19*pm, James Kuyper <(E-Mail Removed)> wrote:
> On 05/03/2012 02:45 PM, John Reye wrote:
>
> > On May 3, 8:14 pm, Nobody wrote:
> >> The compiler is free to lose track of that information during
> >> optimisation, and may well do so.

>
> > char a;
> > char *p = &a;

>
> > a = 1;
> > *p = 2;
> > printf("%d\n", a);

>
> > Does the C standard guarantee, that the value 2 will get printed in
> > the above code??

>
> Yes.
>
> The key point is that *p and a have the same type, so there's no
> violation of the anti-aliasing rules. There's also a special exemption
> in those rules for character types, so the behavior would remain
> well-defined even if 'a' had the type 'int'.


Great, thanks.
(I'm quite relieved, otherwise I might have started sprinkling
unnecessary "volatiles"!!)
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
problem in running a basic code in python 3.3.0 that includes HTML file Satabdi Mukherjee Python 1 04-04-2013 07:48 PM
Why does perl allow so many different ways of doing essentially thesame thing? Peng Yu Perl Misc 23 06-12-2010 10:09 AM
How can I transform source range to destination range that is thesame as source? Lambda C++ 2 07-16-2008 05:18 PM
Once again pointer to first element vs pointer to array cast topointer to element Szabolcs Borsanyi C Programming 6 05-23-2008 11:06 AM
why a class can't access protected method from another class in thesame package,the method is interited from the ohtner class from differntpackage? junzhang1983@gmail.com Java 3 01-28-2008 02:09 AM



Advertisments