public inbox for gcc-cvs@sourceware.org
help / color / mirror / Atom feed
From: Pierre-Marie de Rodat <pmderodat@gcc.gnu.org>
To: gcc-cvs@gcc.gnu.org
Subject: [gcc r13-499] [Ada] Type invariant or postcondition may cause uninitialized memory reads
Date: Mon, 16 May 2022 08:44:59 +0000 (GMT)	[thread overview]
Message-ID: <20220516084459.1140C3857419@sourceware.org> (raw)

https://gcc.gnu.org/g:b32b51902cd97e3a8a2eede10a847688c5f15cde

commit r13-499-gb32b51902cd97e3a8a2eede10a847688c5f15cde
Author: Justin Squirek <squirek@adacore.com>
Date:   Thu Feb 10 23:03:00 2022 +0000

    [Ada] Type invariant or postcondition may cause uninitialized memory reads
    
    This patch corrects an error in the compiler whereby a function
    requiring the generation of a postconditions procedure may cause an
    uninitialized memory read when the return type
    Has_Unconstrained_Elements or is an unconstrained array.
    
    The error occurs because evaluation of postconditions happens within the
    "at end" handler when the temporary result object may go out of scope.
    The patch modifies expansion in the above cases to evaluate
    postconditions at the point of return instead - in order to guarantee
    the result object is valid.
    
    Note that these changes have the side effect of introducing a semantic
    bug such that functions returning types with unconstrained elements will
    have their postconditions/return type invariants evaluated before
    finalization. Work is currently being done to introduce wrappers which
    will solve this problem and remove technical debt in this area.
    
    gcc/ada/
    
            * exp_ch7.adb (Build_Finalizer): Disable late evaluation of
            postconditions for functions returning types which where
            Has_Unconstrained_Elements is true or are unconstrained arrays.

Diff:
---
 gcc/ada/exp_ch7.adb | 35 +++++++++++++++++++++++++++--------
 1 file changed, 27 insertions(+), 8 deletions(-)

diff --git a/gcc/ada/exp_ch7.adb b/gcc/ada/exp_ch7.adb
index ff7eefa6684..ae3663ecdf6 100644
--- a/gcc/ada/exp_ch7.adb
+++ b/gcc/ada/exp_ch7.adb
@@ -4247,14 +4247,33 @@ package body Exp_Ch7 is
          --
          --    Postcond_Enable := False;
 
-         Append_To (Top_Decls,
-           Make_Assignment_Statement (Loc,
-             Name       =>
-               New_Occurrence_Of
-                 (Get_Postcond_Enabled (Def_Ent), Loc),
-             Expression =>
-               New_Occurrence_Of
-                 (Standard_False, Loc)));
+         --  Note that we do not disable early evaluation of postconditions
+         --  for return types that are unconstrained or have unconstrained
+         --  elements since the temporary result object could get allocated on
+         --  the stack and be out of scope at the point where we perform late
+         --  evaluation of postconditions - leading to uninitialized memory
+         --  reads.
+
+         --  This disabling of early evaluation can lead to incorrect run-time
+         --  semantics where functions with unconstrained elements will
+         --  have their corresponding postconditions evaluated before
+         --  finalization. The proper solution here is to generate a wrapper
+         --  to capture the result instead of using multiple flags and playing
+         --  with flags which does not even work in all cases ???
+
+         if not Has_Unconstrained_Elements (Etype (Def_Ent))
+           or else (Is_Array_Type (Etype (Def_Ent))
+                     and then not Is_Constrained (Etype (Def_Ent)))
+         then
+            Append_To (Top_Decls,
+              Make_Assignment_Statement (Loc,
+                Name       =>
+                  New_Occurrence_Of
+                    (Get_Postcond_Enabled (Def_Ent), Loc),
+                Expression =>
+                  New_Occurrence_Of
+                    (Standard_False, Loc)));
+         end if;
 
          --  Add the subprogram to the list of declarations an analyze it


                 reply	other threads:[~2022-05-16  8:44 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220516084459.1140C3857419@sourceware.org \
    --to=pmderodat@gcc.gnu.org \
    --cc=gcc-cvs@gcc.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).