From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-patches-return-451411-listarch-gcc-patches=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 9145 invoked by alias); 11 Apr 2017 10:48:56 -0000
Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-patches.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-help@gcc.gnu.org>
Sender: gcc-patches-owner@gcc.gnu.org
Received: (qmail 128767 invoked by uid 89); 11 Apr 2017 10:48:19 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=
X-HELO: mx2.suse.de
Received: from mx2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 11 Apr 2017 10:48:17 +0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])	by mx2.suse.de (Postfix) with ESMTP id 26135AC3B;	Tue, 11 Apr 2017 10:48:09 +0000 (UTC)
Date: Tue, 11 Apr 2017 10:48:00 -0000
From: Richard Biener <rguenther@suse.de>
To: Florian Weimer <fweimer@redhat.com>
cc: Jonathan Wakely <jwakely@redhat.com>,     Bernd Edlinger <bernd.edlinger@hotmail.de>,     Jakub Jelinek <jakub@redhat.com>, GCC Patches <gcc-patches@gcc.gnu.org>,     Jason Merrill <jason@redhat.com>, Jeff Law <law@redhat.com>
Subject: Re: [PATCH] Add a new type attribute always_alias (PR79671)
In-Reply-To: <e07a3d0b-8a70-02a1-59fe-5962ce4b9cde@redhat.com>
Message-ID: <alpine.LSU.2.20.1704111246410.30715@zhemvz.fhfr.qr>
References: <20170405160333.GR4425@redhat.com> <20170405160849.GV17461@tucnak> <AM4PR0701MB2162884DCF4538DC0FF5C2F1E40A0@AM4PR0701MB2162.eurprd07.prod.outlook.com> <AM4PR0701MB21623337A5C0C1850D3DF4C7E40A0@AM4PR0701MB2162.eurprd07.prod.outlook.com> <alpine.LSU.2.20.1704060925130.30715@zhemvz.fhfr.qr> <20170406075104.GA17461@tucnak> <alpine.LSU.2.20.1704060952480.30715@zhemvz.fhfr.qr> <AM4PR0701MB216235AC9FDCC6D5F8D7C96DE40D0@AM4PR0701MB2162.eurprd07.prod.outlook.com> <7d17b3b7-2d38-6184-8bd6-eb9f96f87912@redhat.com> <alpine.LSU.2.20.1704061623150.30715@zhemvz.fhfr.qr> <20170406144326.GT4425@redhat.com> <f18d9755-81c0-34bc-f453-66c98cba495b@redhat.com> <7738C1DA-5B82-44B2-A647-0DB806484602@suse.de> <e07a3d0b-8a70-02a1-59fe-5962ce4b9cde@redhat.com>
User-Agent: Alpine 2.20 (LSU 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-SW-Source: 2017-04/txt/msg00510.txt.bz2

On Tue, 11 Apr 2017, Florian Weimer wrote:

> On 04/06/2017 09:12 PM, Richard Biener wrote:
> > > 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?
> 
> An example is in libffi/src/closures.c:
> 
>       char buf[MAXPATHLEN * 3];
> 
>       if (getmntent_r (last_mntent, &mnt, buf, sizeof (buf)) == NULL)
>         return -1;
> 
> The intent is that buf is untyped storage, from which the getmntent_r function
> can allocate objects as needed (instead of using malloc).
> 
> Based on your earlier comments, GCC already supports that without any further
> source code annotations.

Yes.

Richard.