This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: RFA: new pass to warn on questionable uses of alloca() and VLAs
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Aldy Hernandez <aldyh at redhat dot com>
- Cc: Martin Sebor <msebor at gmail dot com>, gcc-patches <gcc-patches at gcc dot gnu dot org>, Martin Sebor <msebor at redhat dot com>, Jeff Law <law at redhat dot com>, Andrew MacLeod <amacleod at redhat dot com>
- Date: Mon, 1 Aug 2016 20:35:34 +0000
- Subject: Re: RFA: new pass to warn on questionable uses of alloca() and VLAs
- Authentication-results: sourceware.org; auth=none
- References: <577F9301.10205@redhat.com> <5782C7A3.9050308@gmail.com> <578917C0.4000809@redhat.com> <578AA22C.4050307@gmail.com> <578CB32B.9080602@redhat.com> <578D9B10.6010600@gmail.com> <578E02C7.5050400@redhat.com>
On Tue, 19 Jul 2016, Aldy Hernandez wrote:
> + // Do not warn on VLAs occurring in a loop, since VLAs are
> + // guaranteed to be cleaned up when they go out of scope.
> + // That is, there is a corresponding __builtin_stack_restore
> + // at the end of the scope in which the VLA occurs.
Given this ...
> + case ALLOCA_IN_LOOP:
> + warning_at (loc, wcode,
> + is_vla ? "use of variable-length array "
> + "within a loop"
> + : "use of %<alloca%> within a loop");
> + break;
... why is there a VLA case for this diagnostic at all? I'd expect an
assertion that only the alloca case can reach this diagnostic.
Also, if the format string for a diagnostic function is a ? : conditional
expression you need to mark up each half with G_() so that both halves are
properly extracted for translation. This applies to lots of diagnostics
in this patch.
--
Joseph S. Myers
joseph@codesourcery.com