This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: ToT glibc build problem with ToT GCC
- From: Szabolcs Nagy <Szabolcs dot Nagy at arm dot com>
- To: Carlos O'Donell <carlos at redhat dot com>, Martin Sebor <msebor at gmail dot com>, Steve Ellcey <sellcey at marvell dot com>, "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>
- Cc: nd <nd at arm dot com>, "msebor at redhat dot com" <msebor at redhat dot com>
- Date: Fri, 30 Aug 2019 11:02:22 +0000
- Subject: Re: ToT glibc build problem with ToT GCC
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SBzGSl5Oqk5CUwbVvu1szxCWvCv80vBoWiJojaHvEOQ=; b=H2gikFxUFkSs5tLQr3Co+G4FuTp7d06kj+cYzaPFyLc6tf8l4laASVPoAzxC5FjTjXZky3KAFrVWo2Jfw6qvJHFLUY8qogc1MN3byZZ76Ot7Kg1UEHy+V0+JMAVI7hq2U3G61wDemx42XgLjp50Feie1TgRi4tzJ0GwoXtHGlCrIOY5zXr8o9L/vrnu3V5P201IR/yPlec8mU6jHLnRDdHMiWHu3s0j1pPNxAt0WUqnDGPDtDldLPuJRl5A4r+5QDe+Li7CAiu/2pSJ24oSDXFZuhfr/oDtz4UE2FYGWj0WRAWDiNNfqBRsHY8KxK0AGJ1NvnEZCWaWxActy5GfH1Q==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LxGGqjn31UvhHiRF6ylmPX9FXfLLxq08xi+nYriCB0207QwLF5o/bpwLcGJ6jdbiIb4HygV5ke3d7KSkORmNwz8SAM+1GM92d9GdTBc6SE6v31EjydkZc8bZXYaycVBTC728YXHKdI4qxd2zLI9WR1XGyvtSAHNwafeI/WgZGpt5EzsEPDXrAYs6DEoHqQUeCywE0M7ZNZ9afnoj/OM2A5H1LxBiVrd9uG8mHeQT1jhDqlu/T95t9y3wOayRasD0Qn7ah9JNecg+wxrXWhYEfK/dhEWY0O2fuSrVmR1h3/E7uqFmB2qC/7sUquuTMfbE0UxpGcAXLSprjGrE0jEx8Q==
- Original-authentication-results: spf=none (sender IP is ) smtp.mailfrom=Szabolcs dot Nagy at arm dot com;
- References: <486309d08583ed1c27a001d946205850b421f7ad.camel@marvell.com> <53b36206-3f07-432b-9d0f-02520debe4b8@gmail.com> <d96c9e5d-18f6-9c55-cd49-334c3d449a5b@redhat.com> <2e5c0137-4109-e7ce-8d1d-9c268e086f81@gmail.com> <f67a431b-0d15-644a-c5cd-8cf2ccf8e270@redhat.com>
On 29/08/2019 20:17, Carlos O'Donell wrote:
> Is there a viable solution for a static allocation of a structure
> that ends in a VLA?
flexible array member should be possible to allocate with a union:
static union
{
struct { int nbytes; char bytes[N]; } xxx;
struct { int nbytes; char bytes[]; } replace;
} u;
then u.replace has N extra bytes allocated (and initialized to 0).
(i think you can use u.xxx and u.replace interchangeably with
a lax interpretation of the "common initial sequence" rule
http://port70.net/~nsz/c/c11/n1570.html#6.5.2.3p6 )
if you don't want to repeat the struct type definition then
static union
{
struct foo replace;
char xxx[sizeof(struct foo) + N];
} u;
should work (but the tail bytes are not initialized with this
ordering, the other ordering initializes u.xxx but you have
to rely on type punning when accessing u.replace which is safe
with gcc).
these should not trigger out-of-bounds warnings.