emacs-devel
[Top][All Lists]
Advanced

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

emacs-module.c, eassert, and nonnull args


From: Paul Eggert
Subject: emacs-module.c, eassert, and nonnull args
Date: Sun, 4 Jun 2017 19:48:20 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1

Thanks for your recent improvements to emacs-module.c. One thing I noticed, though, was that it added several easserts. However, there's a comment at the start of emacs-module.c that says "Do NOT use 'eassert'". To play it safe for now I removed the easserts, and thought I'd raise this on emacs-discuss.

As I understand it, emacs-module.c's use of eassert is intended for bugs in Emacs itself, not for bugs in user-supplied modules. Although perhaps we need a more-systematic way of issuing signals for screwups in modules, 'eassert' sounds dicey for that as assertion failures are so drastic. Even though modules can dump core on their own, should Emacs be on high alert and dump core merely because a module has an invalid value? Plus, should ENABLE_CHECKING affect module-screwup checking the same way that it affects eassert?

One other thing. We typically don't need 'eassert (p != NULL)' if P is a pointer that is about to be dereferenced, as Emacs platforms with ENABLE_CHECKING catch null-pointer deferences in the hardware nowadays.

Instead of using runtime checks, perhaps we should decorate emacs-module.h's function declarations with __attribute__ ((__nonnull__ ((N)))) if argument N of a module function is supposed to be nonnull, so that problems in this area can (mostly) be caught statically. We could add a macro like the following to src/emacs-module.h, after the definition of EMACS_NOEXCEPT:

  #if 3 < __GNUC__ + (3 <= __GNUC_MINOR__)
  # define EMACS_ARG_NONNULL(...) __attribute__ ((__nonnull__ ((__VA_ARGS__))))
  #else
  # define EMACS_ARG_NONNULL(...)
  #endif

and then use EMACS_ARG_NONNULL calls for function pointers whose arguments are supposed to be nonnull.



reply via email to

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