Re: [PATCH] Add a new type attribute always_alias (PR79671)

[Florian Weimer <fweimer@redhat.com>]

On 04/06/2017 08:12 PM, Bernd Edlinger wrote:
> On 04/06/17 19:47, Florian Weimer wrote:
>> On 04/06/2017 07:39 PM, Bernd Edlinger wrote:
>>> On 04/06/17 16:17, Florian Weimer wrote:
>>>>> Here is what I want to write in the doc:
>>>>>
>>>>> @item typeless_storage
>>>>> @cindex @code{typeless_storage} type attribute
>>>>> A type declared with this attribute behaves like a character type
>>>>> with respect to aliasing semantics.
>>>>> This is attribute is similar to the @code{may_alias} attribute,
>>>>> except that it is not restricted to pointers.
>>>>
>>>> As Jakub pointed out, this is not what we need here.  An object of type
>>>> char does *not* have untyped storage.  Accessing it as a different type
>>>> is still undefined.
>>>>
>>>
>>> but, do you agree that this is valid in C11?
>>>
>>> typedef char char_a[4];
>>>
>>> int
>>> main (void)
>>> {
>>>    char_a a = {1,2,3,4};
>>>    short *b = (short *) &a;
>>>
>>>    b[1] = 0;
>>>
>>>    if (a[0] == 1 && a[1] == 2 && a[2] == 3 && a[3] == 4)
>>>      abort();
>>>
>>>    exit(0);
>>> }
>>>
>>>
>>> all I want to do is replace "char" with a different type.
>>
>> Thanks a lot for posting a concrete example.
>>
>> The effective type of a[2] and [3] is char.  The character type wildcard
>> in 6.5(7) only applies to the type of the lvalue expression ysed for the
>> access, not the effective type of the object being accessed.  The type
>> of the LHS of the assignment expression is short.  So the access is
>> undefined.
>>
>
> exactly *that* is what I want to make valid with that attribute, which
> would be also useful in C and kernel code, IMHO.

And I think we all agree that this is a laudable goal.

> But isn't the effective type changed by the assignment b[1] = 0;
> as described in 6.5(6):
> "If a value is stored into an object having no declared type through an
> lvalue having a type that is not a character type, then the type of the
> lvalue becomes the effective type of the object for that access and for
> subsequent accesses that do not modify the stored value."

I don't know what your patch does, but your proposed documentation does 
not make this valid because “declared as char” is still not “having no 
declared type”.  Or put differently, “behaves like a character type” is 
not what we actually want here.

Let me repeat that I don't know if this is merely a documentation issue.

Thanks,
Florian