public inbox for gdb-cvs@sourceware.org
help / color / mirror / Atom feed
From: Tom de Vries <vries@sourceware.org>
To: gdb-cvs@sourceware.org
Subject: [binutils-gdb] [gdb/rust] Fix literal truncation
Date: Sat,  4 Jun 2022 11:18:04 +0000 (GMT)	[thread overview]
Message-ID: <20220604111804.09AD13838209@sourceware.org> (raw)

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=1390b65a1b93f75cdd4165f190b4a95b93add66e

commit 1390b65a1b93f75cdd4165f190b4a95b93add66e
Author: Tom de Vries <tdevries@suse.de>
Date:   Sat Jun 4 13:17:33 2022 +0200

    [gdb/rust] Fix literal truncation
    
    Make sure we error out on overflow instead of truncating in all cases.
    
    I've used as overflow string: "Integer literal is too large", based
    on what I found at
    <rust-lang/rust>/src/test/ui/parser/int-literal-too-large-span.rs
    but perhaps someone has a better idea.
    
    Tested on x86_64-linux, with a build with --enable-targets=all.

Diff:
---
 gdb/rust-parse.c                        | 5 ++++-
 gdb/testsuite/gdb.base/parse_number.exp | 5 +++--
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/gdb/rust-parse.c b/gdb/rust-parse.c
index 7d7d882872c..836f49108f8 100644
--- a/gdb/rust-parse.c
+++ b/gdb/rust-parse.c
@@ -1024,7 +1024,10 @@ rust_parser::lex_number ()
 	    }
 	}
 
-      value = strtoulst (number.c_str () + offset, NULL, radix);
+      const char *trailer;
+      value = strtoulst (number.c_str () + offset, &trailer, radix);
+      if (*trailer != '\0')
+	error ("Integer literal is too large");
       if (implicit_i32 && value >= ((uint64_t) 1) << 31)
 	type = get_type ("i64");
 
diff --git a/gdb/testsuite/gdb.base/parse_number.exp b/gdb/testsuite/gdb.base/parse_number.exp
index f9782115b7c..4189ccaf92c 100644
--- a/gdb/testsuite/gdb.base/parse_number.exp
+++ b/gdb/testsuite/gdb.base/parse_number.exp
@@ -113,8 +113,7 @@ proc parse_number { lang n } {
 	    return [list "i64" $n]
 	} else {
 	    # Overflow.
-	    # Some truncated value, should be re_overflow.
-	    return [list i64 $any]
+	    return [list $re_overflow $re_overflow]
 	}
     } elseif { $lang == "d" } {
 	if { [fits_in_type $n 32 s] } {
@@ -274,6 +273,8 @@ proc test_parse_numbers {arch} {
 	    set re_overflow "Overflow on numeric constant\\."
 	} elseif { $lang == "ada" } {
 	    set re_overflow "Integer literal out of range"
+	} elseif { $lang == "rust" } {
+	    set re_overflow "Integer literal is too large"
 	} else {
 	    set re_overflow "Numeric constant too large\\."
 	}


                 reply	other threads:[~2022-06-04 11:18 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=20220604111804.09AD13838209@sourceware.org \
    --to=vries@sourceware.org \
    --cc=gdb-cvs@sourceware.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).