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

[Richard Biener <rguenther@suse.de>]

On April 6, 2017 4:51:01 PM GMT+02:00, Florian Weimer <fweimer@redhat.com> wrote:
>On 04/06/2017 04:43 PM, Jonathan Wakely wrote:
>> On 06/04/17 16:23 +0200, Richard Biener wrote:
>>> On Thu, 6 Apr 2017, Florian Weimer wrote:
>>>
>>>> On 04/06/2017 04:11 PM, Bernd Edlinger wrote:
>>>>
>>>> > I think it is not too complicated to done in the C++ FE.
>>>> > The FE looks for array of std::byte and unsigned char,
>>>> > and sets the attribute when the final type is constructed.
>>>> >
>>>> > What I am trying to do is just extend the semantic of may_alias
>>>> > a bit, and then have the C++ FE use it in the way it has to.
>>>>
>>>> We also need this for some POSIX and Linux kernel interfaces.  A
>>>> C++-only
>>>> solution would not help with that.
>>>
>>> Example(s)?
>>
>> sockaddr_storage comes to mind.
>
>Right.  The kernel also has many APIs which return multiple 
>variable-length data blocks, such as getdents64, and many more 
>interfaces in combination with read/recv system calls.  Variable length
>
>means that you cannot declare the appropriate type after the first data
>
>item, so you technically have to use malloc.
>
>POSIX interfaces which exhibit a similar pattern are getpwnam_r and 
>friends, but for them, you can probably use malloc without ill effect 
>(although there are still performance concerns).

Can you give a concrete example which shows the issue and how typeless_storage helps?

Thanks,
Richard.

>Thanks,
>Florian