From patchwork Fri Aug 30 13:06:29 2019
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Patchwork-Submitter: Florian Weimer <fweimer@redhat.com>
X-Patchwork-Id: 34358
Received: (qmail 26914 invoked by alias); 30 Aug 2019 13:06:37 -0000
Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <libc-alpha.sourceware.org>
List-Unsubscribe: <mailto:libc-alpha-unsubscribe-##L=##H@sourceware.org>
List-Subscribe: <mailto:libc-alpha-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/libc-alpha/>
List-Post: <mailto:libc-alpha@sourceware.org>
List-Help: <mailto:libc-alpha-help@sourceware.org>,
	<http://sourceware.org/ml/#faqs>
Sender: libc-alpha-owner@sourceware.org
Delivered-To: mailing list libc-alpha@sourceware.org
Received: (qmail 26902 invoked by uid 89); 30 Aug 2019 13:06:37 -0000
Authentication-Results: sourceware.org; auth=none
X-Spam-SWARE-Status: No, score=-18.5 required=5.0 tests=AWL, BAYES_00,
	GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3,
	SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.3.1 spammy=
X-HELO: mx1.redhat.com
From: Florian Weimer <fweimer@redhat.com>
To: Carlos O'Donell <carlos@redhat.com>
Cc: Martin Sebor <msebor@gmail.com>, Steve Ellcey <sellcey@marvell.com>,
	"libc-alpha\@sourceware.org" <libc-alpha@sourceware.org>,
	"msebor\@redhat.com" <msebor@redhat.com>
Subject: Re: ToT glibc build problem with ToT GCC
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>
Date: Fri, 30 Aug 2019 15:06:29 +0200
In-Reply-To: <f67a431b-0d15-644a-c5cd-8cf2ccf8e270@redhat.com> (Carlos
	O'Donell's message of "Thu, 29 Aug 2019 15:17:46 -0400")
Message-ID: <87ef126bvu.fsf@oldenburg2.str.redhat.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux)
MIME-Version: 1.0

* Carlos O'Donell:

> Is there a viable solution for a static allocation of a structure
> that ends in a VLA?

Sure, use an initializer.  Not sure if this breaks anything.  The test
suite is clean.

(GNU C obviously didn't support that when the code was written.)

Thanks,
Florian

localedef: Use initializer for flexible array member [BZ #24950]

2019-08-30  Florian Weimer  <fweimer@redhat.com>

	[BZ #24950]
	* locale/programs/charmap.h (struct charseq): Turn bytes into a
	flexible array member.
	* locale/programs/ld-ctype.c (ctype_finish): Use initializer for
	replace.

diff --git a/locale/programs/charmap.h b/locale/programs/charmap.h
index 870a9e9577..70db330d29 100644
--- a/locale/programs/charmap.h
+++ b/locale/programs/charmap.h
@@ -60,7 +60,7 @@ struct charseq
   const char *name;
   uint32_t ucs4;
   int nbytes;
-  unsigned char bytes[0];
+  unsigned char bytes[];
 };
 
 
diff --git a/locale/programs/ld-ctype.c b/locale/programs/ld-ctype.c
index cfc9c43fd5..12d05f1641 100644
--- a/locale/programs/ld-ctype.c
+++ b/locale/programs/ld-ctype.c
@@ -842,8 +842,6 @@ no input digits defined and none of the standard names in the charmap"));
   for (cnt = 0; cnt < 10; ++cnt)
     if (ctype->mboutdigits[cnt] == NULL)
       {
-	static struct charseq replace[2];
-
 	if (!warned)
 	  {
 	    record_error (0, 0, _("\
@@ -851,10 +849,12 @@ not all characters used in `outdigit' are available in the charmap"));
 	    warned = 1;
 	  }
 
-	replace[0].nbytes = 1;
-	replace[0].bytes[0] = '?';
-	replace[0].bytes[1] = '\0';
-	ctype->mboutdigits[cnt] = &replace[0];
+	static const struct charseq replace =
+	  {
+	     .nbytes = 1,
+	     .bytes = { '\0' },
+	  };
+	ctype->mboutdigits[cnt] = (struct charseq *) &replace;
       }
 
   warned = 0;