Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Is this compiler specific or a C rule?

Reply
Thread Tools

Is this compiler specific or a C rule?

 
 
Thad Smith
Guest
Posts: n/a
 
      05-07-2010
aleksa wrote:
> My first post was supposed to show the problem,
> without going too much into details.
>
> For the sake of completeness, here are the sources:
>
> void V1 (POINT* src, RECT* prect)
> {
> POINT pt;
>
> prect->left = INT_MAX;
> prect->bottom = INT_MAX;
> prect->right = INT_MIN;
> prect->top = INT_MIN;
>
> while (1) {
> pt.x = src->x;
> pt.y = src->y;
> src++;
>
> if (pt.x == 0) break;
>
> if (pt.x < prect->left) prect->left = pt.x;
> if (pt.x > prect->right) prect->right = pt.x;
>
> if (pt.y < prect->bottom) prect->bottom = pt.y;
> if (pt.y > prect->top) prect->top = pt.y;
> }
> }


Assume

union {
POINT p;
RECT r;
} u;
....
V1 (&u.p, &u.r);

is in a different module.

With suitable definitions of POINT and RECT, setting prect->left can affect
access to src->x on the next iteration of the loop. The compiler therefore must
store each assignment to members of *prect.

--
Thad
 
Reply With Quote
 
 
 
 
Tim Rentsch
Guest
Posts: n/a
 
      06-17-2010
Nobody <(E-Mail Removed)> writes:

> On Wed, 05 May 2010 16:23:19 +0200, aleksa wrote:
>
>> My first post was supposed to show the problem,
>> without going too much into details.
>>
>> For the sake of completeness, here are the sources:
>>
>> void V1 (POINT* src, RECT* prect)

>
> The compiler must assume that the data referenced via src can overlap
> the data referenced via prect. So modifying e.g. prect->left could modify
> elements of src which will be used later.


Unless a RECT has a POINT inside it, implementations are
not obliged to make such an assumption.

(There are more complicated situations, involving unions,
where implementations must allow for such possible overlap,
but those don't hold in the example since no union type
definitions are visible at the point V1 is defined.)
 
Reply With Quote
 
 
 
 
Eric Sosman
Guest
Posts: n/a
 
      06-17-2010
On 6/17/2010 1:11 PM, Tim Rentsch wrote:
> Nobody<(E-Mail Removed)> writes:
> [... on 05 May 2010 ...]
>> On Wed, 05 May 2010 16:23:19 +0200, aleksa wrote:
>> [...]


Tim, is there anyone named "van Winkle" in your family tree?

--
Eric Sosman
http://www.velocityreviews.com/forums/(E-Mail Removed)lid
 
Reply With Quote
 
Tim Rentsch
Guest
Posts: n/a
 
      06-17-2010
Thad Smith <(E-Mail Removed)> writes:

> aleksa wrote:
>> My first post was supposed to show the problem,
>> without going too much into details.
>>
>> For the sake of completeness, here are the sources:
>>
>> void V1 (POINT* src, RECT* prect)
>> {
>> POINT pt;
>>
>> prect->left = INT_MAX;
>> prect->bottom = INT_MAX;
>> prect->right = INT_MIN;
>> prect->top = INT_MIN;
>>
>> while (1) {
>> pt.x = src->x;
>> pt.y = src->y;
>> src++;
>>
>> if (pt.x == 0) break;
>>
>> if (pt.x < prect->left) prect->left = pt.x;
>> if (pt.x > prect->right) prect->right = pt.x;
>>
>> if (pt.y < prect->bottom) prect->bottom = pt.y;
>> if (pt.y > prect->top) prect->top = pt.y;
>> }
>> }

>
> Assume
>
> union {
> POINT p;
> RECT r;
> } u;
> ...
> V1 (&u.p, &u.r);
>
> is in a different module.
>
> With suitable definitions of POINT and RECT, setting prect->left can
> affect access to src->x on the next iteration of the loop. The
> compiler therefore must store each assignment to members of *prect.


Not if the union definition isn't visible at the definition
of V1. Just because such a union type might be (or is)
defined in another translation unit does not affect what
happens at the point the function V1 is compiled.
See 6.5.2.3p5, more specifically:

One special guarantee is made in order to simplify the
use of unions: if a union contains several structures
that share a common initial sequence (see below), and if
the union object currently contains one of these
structures, it is permitted to inspect the common
initial part of any of them anywhere that a declaration
of the complete type of the union is visible.

Notice the final qualifying clause: "anywhere that a declaration
of the complete type of the union is visible." If the union type
definition isn't visible, the provision doesn't come into play.
 
Reply With Quote
 
Thad Smith
Guest
Posts: n/a
 
      06-18-2010
Tim Rentsch wrote:
> Thad Smith <(E-Mail Removed)> writes:
>
>> aleksa wrote:
>>> My first post was supposed to show the problem,
>>> without going too much into details.
>>>
>>> For the sake of completeness, here are the sources:
>>>
>>> void V1 (POINT* src, RECT* prect)
>>> {
>>> POINT pt;
>>>
>>> prect->left = INT_MAX;
>>> prect->bottom = INT_MAX;
>>> prect->right = INT_MIN;
>>> prect->top = INT_MIN;
>>>
>>> while (1) {
>>> pt.x = src->x;
>>> pt.y = src->y;
>>> src++;
>>>
>>> if (pt.x == 0) break;
>>>
>>> if (pt.x < prect->left) prect->left = pt.x;
>>> if (pt.x > prect->right) prect->right = pt.x;
>>>
>>> if (pt.y < prect->bottom) prect->bottom = pt.y;
>>> if (pt.y > prect->top) prect->top = pt.y;
>>> }
>>> }

>> Assume
>>
>> union {
>> POINT p;
>> RECT r;
>> } u;
>> ...
>> V1 (&u.p, &u.r);
>>
>> is in a different module.
>>
>> With suitable definitions of POINT and RECT, setting prect->left can
>> affect access to src->x on the next iteration of the loop. The
>> compiler therefore must store each assignment to members of *prect.

>
> Not if the union definition isn't visible at the definition
> of V1. Just because such a union type might be (or is)
> defined in another translation unit does not affect what
> happens at the point the function V1 is compiled.


I think you misunderstand. If the compiler, before generating code for V1, can
see all instances of calls to V1 and deduce, from the parameters, and sources of
those parameters, that there is no overlap of pointed-to objects, then it can
optimize accordingly. Without that visibility it is required to assume an
overlap may occur such that a storage through one pointer may affect the value
accessible through another. The restrict qualifier allows you to promise to the
compiler that no such multiple pointer reference paths exist.

I think that the compiler could deduce that, say, a storage of a pointer won't
affect the value a double, since the result of setting a object area with
pointer and reading as a double is undefined.

> See 6.5.2.3p5, more specifically:
>
> One special guarantee is made in order to simplify the
> use of unions: if a union contains several structures
> that share a common initial sequence (see below), and if
> the union object currently contains one of these
> structures, it is permitted to inspect the common
> initial part of any of them anywhere that a declaration
> of the complete type of the union is visible.
>
> Notice the final qualifying clause: "anywhere that a declaration
> of the complete type of the union is visible." If the union type
> definition isn't visible, the provision doesn't come into play.


What you say is true, but it provides guarantees of object coincidence for
common initial sequences of structs within a union. Union of common initial
sequences is not the issue and no such guarantee is being sought by the example
code. The paragraph has no impact on the issue at hand.

--
Thad
 
Reply With Quote
 
Tim Rentsch
Guest
Posts: n/a
 
      06-20-2010
Eric Sosman <(E-Mail Removed)> writes:

> On 6/17/2010 1:11 PM, Tim Rentsch wrote:
>> Nobody<(E-Mail Removed)> writes:
>> [... on 05 May 2010 ...]
>>> On Wed, 05 May 2010 16:23:19 +0200, aleksa wrote:
>>> [...]

>
> Tim, is there anyone named "van Winkle" in your family tree?


Alas, I don't always have the luxury of reading newsgroups (especially
comp.lang.c) regularly or responding in a timely fashion.
 
Reply With Quote
 
Tim Rentsch
Guest
Posts: n/a
 
      06-20-2010
Thad Smith <(E-Mail Removed)> writes:

> Tim Rentsch wrote:
>> Thad Smith <(E-Mail Removed)> writes:
>>
>>> aleksa wrote:
>>>> My first post was supposed to show the problem,
>>>> without going too much into details.
>>>>
>>>> For the sake of completeness, here are the sources:
>>>>
>>>> void V1 (POINT* src, RECT* prect)
>>>> {
>>>> POINT pt;
>>>>
>>>> prect->left = INT_MAX;
>>>> prect->bottom = INT_MAX;
>>>> prect->right = INT_MIN;
>>>> prect->top = INT_MIN;
>>>>
>>>> while (1) {
>>>> pt.x = src->x;
>>>> pt.y = src->y;
>>>> src++;
>>>>
>>>> if (pt.x == 0) break;
>>>>
>>>> if (pt.x < prect->left) prect->left = pt.x;
>>>> if (pt.x > prect->right) prect->right = pt.x;
>>>>
>>>> if (pt.y < prect->bottom) prect->bottom = pt.y;
>>>> if (pt.y > prect->top) prect->top = pt.y;
>>>> }
>>>> }
>>> Assume
>>>
>>> union {
>>> POINT p;
>>> RECT r;
>>> } u;
>>> ...
>>> V1 (&u.p, &u.r);
>>>
>>> is in a different module.
>>>
>>> With suitable definitions of POINT and RECT, setting prect->left can
>>> affect access to src->x on the next iteration of the loop. The
>>> compiler therefore must store each assignment to members of *prect.

>>
>> Not if the union definition isn't visible at the definition
>> of V1. Just because such a union type might be (or is)
>> defined in another translation unit does not affect what
>> happens at the point the function V1 is compiled.

>
> I think you misunderstand. If the compiler, before generating code
> for V1, can see all instances of calls to V1 and deduce, from the
> parameters, and sources of those parameters, that there is no overlap
> of pointed-to objects, then it can optimize accordingly. Without that
> visibility it is required to assume an overlap may occur such that a
> storage through one pointer may affect the value accessible through
> another.


I believe you are mistaken. The rules for effective type
mean the compiler may ignore possible overlap, even if it
can't see all the calls to V1.

> The restrict qualifier allows you to promise to the compiler
> that no such multiple pointer reference paths exist.
>
> I think that the compiler could deduce that, say, a storage of a
> pointer won't affect the value a double, since the result of setting a
> object area with pointer and reading as a double is undefined.


What you may be missing is that the pointers in question are
pointers to structs, and the effective type access rules
apply to the struct objects as well as the individual members
in them.


>> See 6.5.2.3p5, more specifically:
>>
>> One special guarantee is made in order to simplify the
>> use of unions: if a union contains several structures
>> that share a common initial sequence (see below), and if
>> the union object currently contains one of these
>> structures, it is permitted to inspect the common
>> initial part of any of them anywhere that a declaration
>> of the complete type of the union is visible.
>>
>> Notice the final qualifying clause: "anywhere that a declaration
>> of the complete type of the union is visible." If the union type
>> definition isn't visible, the provision doesn't come into play.

>
> What you say is true, but it provides guarantees of object coincidence
> for common initial sequences of structs within a union. Union of
> common initial sequences is not the issue and no such guarantee is
> being sought by the example code. The paragraph has no impact on the
> issue at hand.


It's relevant because it's the only situation for accessing
structs that the compiler /does/ have to consider the possibility
of overlap. In all other cases (assuming one struct is not
a subobject of the other), pointers to distinct struct types
may be assumed not to overlap. The paragraph quoted above
is the only exception; since it doesn't apply, the compiler
is free to treat accesses to members in the different structs
as independent.
 
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
XML parsing problem finding a specific element in a specific place mazdotnet ASP .Net 2 10-02-2009 10:07 AM
Parsing DOM to search specific tags with specific custom attribute William FERRERES Javascript 7 07-09-2007 08:11 PM
Is ViwState Page-Specific or UserControl-Specific =?Utf-8?B?SmF2?= ASP .Net 2 08-16-2006 09:30 PM
redirect traffic on specific ip to specific interface mimiseh Cisco 3 06-05-2005 09:14 PM
How do you make sure a frameset is loaded? I'm trying to open a frameset in a new window which shows a specific html page in a specific frame ck388 Javascript 1 09-24-2003 08:32 PM



Advertisments