From: Bruno Haible <bruno@clisp.org>
To: "Pádraig Brady" <P@draigbrady.com>
Cc: bug-gnulib@gnu.org
Subject: Re: VLA and alloca
Date: Sun, 20 Jan 2019 11:19:06 +0100 [thread overview]
Message-ID: <16470327.KXOAg9fI0z@omega> (raw)
In-Reply-To: <2f26e4a4-c899-686c-473c-2c7773fff14b@draigBrady.com>
Paul,
Pádraig Brady wrote:
> I've pushed this with some comments at the current single GNULIB_NO_VLA usage.
How about making use of this GNULIB_NO_VLA macro in all places that assume
VLA syntax? I'm proposing this patch:
2019-01-20 Bruno Haible <bruno@clisp.org>
vla: Consider GNULIB_NO_VLA.
* lib/vla.h (VLA_ELEMS): Define to empty if GNULIB_NO_VLA is defined.
diff --git a/lib/vla.h b/lib/vla.h
index f6ebba0..fa5f39a 100644
--- a/lib/vla.h
+++ b/lib/vla.h
@@ -17,10 +17,21 @@
Written by Paul Eggert. */
-/* A function's argument must point to an array with at least N elements.
+/* GNULIB_NO_VLA can be defined to disable use of VLAs even if supported.
+ This relates to the -Wvla and -Wvla-larger-than warnings, enabled in
+ the default GCC many warnings set. This allows programs to disable use
+ of VLAs, which may be unintended, or may be awkward to support portably,
+ or may have security implications due to non-deterministic stack usage. */
+
+/* Types and variables which are variable-length arrays can be used without
+ particular macros. */
+
+/* VLA_ELEMS is a helper macro used for declaring a function parameter that
+ is a variable-length array.
+ A function's argument must point to an array with at least N elements.
Example: 'int main (int argc, char *argv[VLA_ELEMS (argc)]);'. */
-#ifdef __STDC_NO_VLA__
+#if defined __STDC_NO_VLA__ || defined GNULIB_NO_VLA
# define VLA_ELEMS(n)
#else
# define VLA_ELEMS(n) static n
next prev parent reply other threads:[~2019-01-20 10:19 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-09 22:32 Correct but unhelpful VLA warning vs. gnulib's gettext.h; can we eliminate the false positive? James Youngman
2011-07-10 4:47 ` Paul Eggert
2011-07-10 9:16 ` James Youngman
2011-07-11 0:11 ` Paul Eggert
2011-07-11 1:02 ` James Youngman
2011-07-11 1:13 ` Paul Eggert
2011-07-10 9:48 ` Simon Josefsson
2019-01-14 6:10 ` Pádraig Brady
2019-01-15 1:57 ` VLA and alloca Bruno Haible
2019-01-20 4:46 ` Pádraig Brady
2019-01-20 10:19 ` Bruno Haible [this message]
2019-01-20 21:03 ` Pádraig Brady
2019-02-02 22:44 ` Paul Eggert
2019-01-20 15:36 ` Bruno Haible
2019-01-24 11:51 ` Tim Rühsen
2019-02-02 22:58 ` Paul Eggert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.gnu.org/mailman/listinfo/bug-gnulib
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=16470327.KXOAg9fI0z@omega \
--to=bruno@clisp.org \
--cc=P@draigbrady.com \
--cc=bug-gnulib@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).