emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.


From: Paul Eggert
Subject: Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.
Date: Fri, 1 Apr 2016 01:29:36 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0

Philipp Stephani wrote:

Why did you remove the checks? I think all of them are necessary
and lead to undefined behavior if they are violated.

Looking at my patch:

-      verify (EMACS_INT_MAX > MOST_POSITIVE_FIXNUM);

EMACS_INT_MAX cannot possibly be less than MOST_POSITIVE_FIXNUM, since MOST_POSITIVE_FIXNUM is an EMACS_INT.

       EMACS_INT refcount = XFASTINT (value) + 1;
-      if (FIXNUM_OVERFLOW_P (refcount)) xsignal0 (Qoverflow_error);
+      if (MOST_POSITIVE_FIXNUM < refcount)
+       xsignal0 (Qoverflow_error);

Adding 1 to the result of XFASTINT cannot possibly yield an integer that is less than MOST_NEGATIVE_FIXNUM, so there's no need for the extra runtime check that FIXNUM_OVERFLOW_P would impose.

   ptrdiff_t raw_size = SBYTES (lisp_str_utf8);
-  if (raw_size == PTRDIFF_MAX) xsignal0 (Qoverflow_error);

raw_size cannot possibly be PTRDIFF_MAX, since SBYTES always returns a value no greater than STRING_BYTES_BOUND, and STRING_BYTES_BOUND is less than PTRDIFF_MAX.

-  if (length > STRING_BYTES_BOUND) xsignal0 (Qoverflow_error);
   Lisp_Object lstr = make_unibyte_string (str, length);

make_unibyte_string already checks for string length overflow, so the caller need not check this.

-  if (FIXNUM_OVERFLOW_P (i)) xsignal0 (Qoverflow_error);
   CHECK_RANGED_INTEGER (make_number (i), 0, ASIZE (lvec) - 1);

CHECK_RANGED_INTEGER already checks that the integer is in range, so the caller doesn't need to check that again. Hmm, here, though, there is a problem, in that make_number can silently overflow. Sorry about that. I fixed this by installing the attached further patch.


if one of the used functions is
changed to throw signals

We shouldn't have to worry about that. Changing core functions to throw signals would break lots of other code. We don't need to burden readers of these common core functions with every single design constraint that affects them. It'd be OK to put this commentary somewhere else, just not in a place where it clutters up the main code.

Attachment: 0001-Fix-check-for-subscript-errors-in-module-calls.patch
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]