public inbox for gcc-cvs@sourceware.org
help / color / mirror / Atom feed
From: Thomas Schwinge <tschwinge@gcc.gnu.org>
To: gcc-cvs@gcc.gnu.org
Subject: [gcc/devel/rust/master] lexer: Add reference and warning documentation
Date: Wed,  8 Jun 2022 12:14:31 +0000 (GMT)	[thread overview]
Message-ID: <20220608121431.23361380FDDD@sourceware.org> (raw)

https://gcc.gnu.org/g:45eac568686745af73848f6c238fefcd87e315de

commit 45eac568686745af73848f6c238fefcd87e315de
Author: Arthur Cohen <arthur.cohen@embecosm.com>
Date:   Wed Mar 2 15:18:40 2022 +0100

    lexer: Add reference and warning documentation
    
    Fixes the -fself-test invalid memory accesses and adds documentation
    regarding a possible future fix.
    
    Co-authored-by: tschwinge <thomas@schwinge.name>
    Co-authored-by: philberty <philip.herron@embecosm.com>

Diff:
---
 gcc/rust/lex/rust-lex.h | 25 ++++++++++++++++++++++++-
 1 file changed, 24 insertions(+), 1 deletion(-)

diff --git a/gcc/rust/lex/rust-lex.h b/gcc/rust/lex/rust-lex.h
index c50f63208de..039c783c564 100644
--- a/gcc/rust/lex/rust-lex.h
+++ b/gcc/rust/lex/rust-lex.h
@@ -144,7 +144,30 @@ public:
   /**
    * Lex the contents of a string instead of a file
    */
-  static Lexer lex_string (std::string input)
+  // FIXME: This is unsafe!
+  // Since we are taking a reference to the string's internal buffer, we must
+  // ensure that the lexer does not outlive the string, which might not always
+  // be the case.
+  //
+  // We could have a fix, which would include using fmemopen() to allocate a
+  // buffer and copy the string inside it.
+  // ```
+  // // There will be an extra nul-terminator byte written on fclose(), so
+  // // account for that
+  // auto string_file = fmemopen(NULL, input.length() + 1, "wr");
+  // fwrite(input.c_str(), sizeof(char), input.length(), string_file);
+  // auto wrapper = RAIIFile(string_file);
+  // ```
+  // But sadly our RAIIFile does not support moving really well... And the
+  // destructor, which calls fclose(), gets called, triggering a lack of a
+  // buffer to parse :)
+  //
+  // We need to look into fixing the RAIIFile so that it supports this
+  // behaviour. I'm assuming this will be something like fixing one of the copy
+  // or move constructors, but is outside of the scope of this fix. For now,
+  // make sure your lexers don't live longer than the strings they're trying
+  // to lex
+  static Lexer lex_string (std::string &input)
   {
     // We can perform this ugly cast to a non-const char* since we're only
     // *reading* the string. This would not be valid if we were doing any


                 reply	other threads:[~2022-06-08 12:14 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=20220608121431.23361380FDDD@sourceware.org \
    --to=tschwinge@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).