unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Paul Eggert <eggert@cs.ucla.edu>
To: 8344@debbugs.gnu.org
Subject: bug#8344: (substring ...) crashes on large vectors
Date: Fri, 25 Mar 2011 11:17:30 -0700	[thread overview]
Message-ID: <4D8CDC3A.4010705@cs.ucla.edu> (raw)

I found this problem while compiling the Emacs trunk with
gcc -Wstrict-overflow.

Currently, on a 64-bit machine, (substring VEC FROM TO)
fails if TO and FROM are valid indexes and
TO - FROM is 2**31 or greater.  On typical hosts there
can be buffer overruns or crashes.

The problem is that (substring ...) internally calls
(vector ...), and (vector ...) cannot create a vector
whose length is 2**31 or greater, because it follows
the Emacs convention that varargs functions count the
number of arguments using an 'int'.

The simplest and most general way to address this problem
is to change the Emacs convention to use EMACS_INT rather
than 'int' to count the number of arguments to a function.
I'm preparing a patch along those lines.  The changes
to lisp.h are below; the other changes should be
straightforward albeit tedious.

Before I work any more on this, can anyone see why not
to do this?

=== modified file 'src/lisp.h'
--- src/lisp.h	2011-03-22 09:08:11 +0000
+++ src/lisp.h	2011-03-24 08:54:15 +0000
@@ -964,7 +964,7 @@ struct Lisp_Subr
       Lisp_Object (*a7) (Lisp_Object, Lisp_Object, Lisp_Object, Lisp_Object, Lisp_Object, Lisp_Object, Lisp_Object);
       Lisp_Object (*a8) (Lisp_Object, Lisp_Object, Lisp_Object, Lisp_Object, Lisp_Object, Lisp_Object, Lisp_Object, Lisp_Object);
       Lisp_Object (*aUNEVALLED) (Lisp_Object args);
-      Lisp_Object (*aMANY) (int, Lisp_Object *);
+      Lisp_Object (*aMANY) (EMACS_INT, Lisp_Object *);
     } function;
     short min_args, max_args;
     const char *symbol_name;
@@ -1809,7 +1809,7 @@ typedef struct {
 
 /* Note that the weird token-substitution semantics of ANSI C makes
    this work for MANY and UNEVALLED.  */
-#define DEFUN_ARGS_MANY		(int, Lisp_Object *)
+#define DEFUN_ARGS_MANY		(EMACS_INT, Lisp_Object *)
 #define DEFUN_ARGS_UNEVALLED	(Lisp_Object)
 #define DEFUN_ARGS_0	(void)
 #define DEFUN_ARGS_1	(Lisp_Object)
@@ -2079,7 +2079,7 @@ struct gcpro
   volatile Lisp_Object *var;
 
   /* Number of consecutive protected variables.  */
-  int nvars;
+  EMACS_INT nvars;
 
 #ifdef DEBUG_GCPRO
   int level;
@@ -2860,7 +2860,7 @@ extern Lisp_Object internal_lisp_conditi
 extern Lisp_Object internal_condition_case (Lisp_Object (*) (void), Lisp_Object, Lisp_Object (*) (Lisp_Object));
 extern Lisp_Object internal_condition_case_1 (Lisp_Object (*) (Lisp_Object), Lisp_Object, Lisp_Object, Lisp_Object (*) (Lisp_Object));
 extern Lisp_Object internal_condition_case_2 (Lisp_Object (*) (Lisp_Object, Lisp_Object), Lisp_Object, Lisp_Object, Lisp_Object, Lisp_Object (*) (Lisp_Object));
-extern Lisp_Object internal_condition_case_n (Lisp_Object (*) (int, Lisp_Object *), int, Lisp_Object *, Lisp_Object, Lisp_Object (*) (Lisp_Object));
+extern Lisp_Object internal_condition_case_n (Lisp_Object (*) (EMACS_INT, Lisp_Object *), EMACS_INT, Lisp_Object *, Lisp_Object, Lisp_Object (*) (Lisp_Object));
 extern void specbind (Lisp_Object, Lisp_Object);
 extern void record_unwind_protect (Lisp_Object (*) (Lisp_Object), Lisp_Object);
 extern Lisp_Object unbind_to (int, Lisp_Object);
@@ -2870,7 +2870,7 @@ extern void do_autoload (Lisp_Object, Li
 extern Lisp_Object un_autoload (Lisp_Object);
 EXFUN (Ffetch_bytecode, 1);
 extern void init_eval_once (void);
-extern Lisp_Object safe_call (int, Lisp_Object *);
+extern Lisp_Object safe_call (EMACS_INT, Lisp_Object *);
 extern Lisp_Object safe_call1 (Lisp_Object, Lisp_Object);
 extern Lisp_Object safe_call2 (Lisp_Object, Lisp_Object, Lisp_Object);
 extern void init_eval (void);






             reply	other threads:[~2011-03-25 18:17 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-25 18:17 Paul Eggert [this message]
2011-03-25 21:24 ` bug#8344: (substring ...) crashes on large vectors Stefan Monnier
2011-03-25 21:48   ` Paul Eggert
2011-03-27  2:18     ` Paul Eggert
2011-03-27  7:52       ` Andreas Schwab
2011-03-27  9:09         ` 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://www.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to=4D8CDC3A.4010705@cs.ucla.edu \
    --to=eggert@cs.ucla.edu \
    --cc=8344@debbugs.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.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

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).