From: Paul Eggert <eggert@cs.ucla.edu>
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: FACE_FROM_ID vs FACE_OPT_FROM_ID
Date: Fri, 24 Jun 2016 11:27:26 +0200 [thread overview]
Message-ID: <576CFCFE.8050908@cs.ucla.edu> (raw)
In-Reply-To: <8360sz2cpc.fsf@gnu.org>
On 06/24/2016 10:49 AM, Eli Zaretskii wrote:
> Yes, and on purpose. If the face pointer cannot be determined from its
> ID, we have no other alternative but crash (or abort) anyway.
Of course, and FACE_FROM_ID is intended to be used in situations like
this. However, in some cases the caller can handle the situation where a
face pointer cannot be determined from its ID, and FACE_OPT_FROM_ID is
intended to be used in those cases. It is helpful to the reader (at
least, to this reader) to easily see which case is which.
> When the face ID is not a valid value, as tested against
> FRAME_FACE_CACHE (F)->used, ... FACE_FROM_ID(F, ID), ... when compiled
> without --enable-checking, will index the FRAME_FACE_CACHE
> (F)->face_by_id[] array with an invalid index, and either segfault or
> produce some random garbage that will cause trouble elsewhere. So we
> are not solving a real problem here
?! Yes we are. The eassert is helpful, since it reliably crashes Emacs
when ID is out-of-range, something that is useful when debugging. On all
platforms I know of there is no need to add an eassert that the
resulting pointer is non-null, since the caller is about to dereference
it anyway and that will reliably cause a crash. However, it is helpful
to eassert that ID is in range, since most modern platforms lack
reliable subscript checking.
With FACE_FROM_ID, the ID should never be out-of-range if Emacs is
written correctly, so it's OK to omit the runtime check from production
code, for performance. This is not true for FACE_OPT_FROM_ID; it is
supposed to return NULL when ID is out of range, and callers are
supposed to avoid dereferencing the resulting pointer if it is NULL.
> just shutting up the (stupid, IMO) warning from a compiler
It is not a stupid warning. It is a useful warning. The modern trend in
statically-typed languages is to distinguish "possibly-null pointer to
X" from "non-null pointer to X". That way, a compile-time check can
reliably detect the error of dereferencing null pointers, which is a
real problem in many applications (including Emacs). C does not have
this notion directly and in general a C compiler cannot detect the error
statically. That being said, GCC has reasonable heuristics to check for
the error in many cases, and it's useful to enable this checking to
catch silly programming errors. (Of course code that you and I write
would never have these errors; it's always *other* people's code. :-)
> eassert (face); if (!face) { ...}
eassert (X) means that X must be nonzero, so there should never be a
need for a runtime check !X after a call to eassert (X).
next prev parent reply other threads:[~2016-06-24 9:27 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-23 20:03 FACE_FROM_ID vs FACE_OPT_FROM_ID Eli Zaretskii
2016-06-24 0:23 ` Paul Eggert
2016-06-24 8:49 ` Eli Zaretskii
2016-06-24 9:27 ` Paul Eggert [this message]
2016-06-24 9:57 ` Eli Zaretskii
2016-06-24 10:00 ` Eli Zaretskii
2016-06-24 11:17 ` Paul Eggert
2016-06-24 13:43 ` Eli Zaretskii
2016-06-24 21:34 ` Paul Eggert
2016-06-25 7:48 ` Eli Zaretskii
2016-06-25 21:34 ` Paul Eggert
2016-07-02 9:50 ` Eli Zaretskii
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=576CFCFE.8050908@cs.ucla.edu \
--to=eggert@cs.ucla.edu \
--cc=eliz@gnu.org \
--cc=emacs-devel@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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.