_Region_Get and strict aliasing

[Sergei Organov]

"accounts" <accounts at sakuraindustries.com> writes:

[...]
> Well Region_Control* is the type used to acess the object returned
> from _Region_Get, but its effective type (in that locality, thanks to
> inlining) is actually an "Objects_Control*".

No. You can't change object type by converting pointers. There is some
object in memory and it has static type. If that object is of type
Region_Control, then accessing it through Region_Control* is OK. The
standard doesn't say anything about "locality".

Or maybe I just don't understand what you are trying to explain.

> The C99 spec does not say it is OK to alias as long as you don't use
> the original effective type as well, even if the original effective
> type is a temporary result returned from a function.

The function doesn't return object itself, -- it returns a
pointer. Changing type of pointer doesn't change the type of object the
pointer points to. Thus, your sentence above has no sense for me.

>
> There are about 9 places in the code that use _Region_Get and they are all 
> suspect non C99 conformant aliases.  Rather than list them here, I recomend 
> a quick grep of your copy of the tree.
>
> But as an example, rtems_region_delete (regiondelete.c, ln 53)
> Declares:
> register Region_Control *the_region;
>
> and then initialises it with:
> the_region = (inline expanded) (Region_Cotrol*)_Objects_Get_no_protection
> (...)
>    // alias the Object_Control* returned by _Objects_Get_no_protection to a 
> Region_Control*
>
> and then uses it with:
> &the_region->Object
>
> Which results in a dereference of the alias pointer as a Region_Control* 
> when it has an effective type of a Object_Control*

I fail to follow. An effective type of object in memory has nothing to
do with some pointer that at some time happened to contain the address
of this object, e.g.,

int a;
void *p = (void*)&a;

doesn't change effective type of 'a' to 'void'.

> There is no way the compiler can at this locality determine if 
> Object_Control* really has an effective type of Region_Control* so this is 
> an illegal alias as far as I can understand the C99 spec.

That doesn't match my understanding of the standard. First, I found
nothing in the standard talking about some 'locality'. Is it your own
invention? If so, I'm afraid it doesn't help to explain anything, just
make the issues even harder to understand.

>> 
>> In this particular case, if you get a pointer from
>> _Objects_Get_no_protection that has Object_Control* type but still
>> points to an instance of Region_Control, then converting Object_Control*
>> to Region_Control* and then accessing the object using the latter
>> pointer is perfectly fine.

> That is the point, it doesn't point to a Region_Control* because there is no 
> way for the compiler to determine that it does.  Accordingly the compiler 
> can only deduce that the effective type is actually an
> "Objects_Control*"

I don't care. It's not my problem. Compiler should adhere to the
standard. If the object is indeed of type Region_Control, then according
to the standard, accessing it through Region_Control* is fine. If
compiler can't (currently) figure this out, it must be conservative and
behave as if it is Region_Control.

[...]

>> Well, you still focus on pointer type conversions that are only
>> indirectly related to the aliasing rules. I.e., without pointer
>> conversions it's impossible to violate aliasing rules, but having
>> pointer conversions doesn't necessarily violates aliasing rules.
>> 
> By my reading accessing any pointer type that is not the effective type of 
> the object breaks the rule (apart from the small limitations to 
> allowability).  If a pointer starts out life in one locality as a blah* and 
> is cast into a phht* then phht* is an alias of the effective type which is 
> blah* accessing phht* is an illegal operation.

What is 'locality'? Searching for this word in the draft of the standard
brings 0 results. Are we reading standard or building our own
interpretations? 

>
>> Yes, any code that converts pointer types should be examined, but
>> saying that every such place does violate aliasing rules is not right.
>> 
>> Or is it me who doesn't get it?
>
> The fact that the C99 spec (in this regard) is so able to be argued about 
> for so long by so many people (all of which seem to have at least moderate 
> intelligence an experience, and many of which have large experience and are 
> seemingly highly intelligent) and there is a large difference of opinion as 
> to what is allowble and what isn't, and compilers can not even generate 
> comprehensive warnings on the issue, because it is so difficult to detect 
> with certainty, to me, indicates a specification that is fundamentally 
> flawed and imprecisely defined.  Otherwise there would be no argument and 
> warnings (or better errors) could be produced with certainty.

No, I don't think it's the case. The rules are specified so that
compiler doesn't need to be very clever and analyze the whole program to
perform some optimizations, but producing reliable warnings on rules
violation does involve entire code analysis that, say, GCC can't
currently perform.

Another issue is that people involved in the standardization process are
more experienced in those issues than an average programmer. I'm sure
they've weighted all pros and cons before making the decision.

-- Sergei.