From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Philipp Stephani Newsgroups: gmane.emacs.devel Subject: Re: Dynamic loading progress Date: Fri, 20 Nov 2015 19:29:49 +0000 Message-ID: References: <8737wgw7kf.fsf@lifelogs.com> <87io5bv1it.fsf@lifelogs.com> <87egfzuwca.fsf@lifelogs.com> <876118u6f2.fsf@lifelogs.com> <8737w3qero.fsf@lifelogs.com> <831tbn9g9j.fsf@gnu.org> <878u5upw7o.fsf@lifelogs.com> <83ziya8xph.fsf@gnu.org> <83y4du80xo.fsf@gnu.org> <564E6081.9010805@cs.ucla.edu> <564E6352.20701@cs.ucla.edu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a114b6af6a6c34b0524fde607 X-Trace: ger.gmane.org 1448047807 13096 80.91.229.3 (20 Nov 2015 19:30:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 20 Nov 2015 19:30:07 +0000 (UTC) Cc: emacs-devel@gnu.org To: Paul Eggert , Eli Zaretskii , Ted Zlatanov , =?UTF-8?Q?Aur=C3=A9lien_Aptel?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 20 20:30:06 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZzrNm-0007hU-6A for ged-emacs-devel@m.gmane.org; Fri, 20 Nov 2015 20:30:06 +0100 Original-Received: from localhost ([::1]:49521 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZzrNl-0007uh-FZ for ged-emacs-devel@m.gmane.org; Fri, 20 Nov 2015 14:30:05 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50355) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZzrNh-0007uT-Uh for emacs-devel@gnu.org; Fri, 20 Nov 2015 14:30:03 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZzrNg-0008Ny-SJ for emacs-devel@gnu.org; Fri, 20 Nov 2015 14:30:01 -0500 Original-Received: from mail-wm0-x229.google.com ([2a00:1450:400c:c09::229]:32906) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZzrNf-0008ME-02; Fri, 20 Nov 2015 14:29:59 -0500 Original-Received: by wmec201 with SMTP id c201so86064277wme.0; Fri, 20 Nov 2015 11:29:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=VlxaBVJ+2PrFuQ8pZ0XtmNhk10p6YBrch/3f5J8sBho=; b=rlNtzF5OJz0h+bjbd9nw9nzNCRyJzY/6/QlejXUSe1zZlDfd938OI01mZA39wNIhqp rTkwS1RxD27gyGWZf4HquHNa4iZrEjU59RHWIwE3YWaRqAUGr7+9YVLun+OiCTPTGAIA go8+hJS2PZjn3iq5B6yOieUsWmrkPkAM4I+mHimzMg/cVCugyjsHxsx0QT2QxDFN/S2b MrhCi5/vubdS+zGm8syCmkfpU1O4ebbiycJplfCyxGza+4ArjnrfDDtOe2LjQBFvRs8x PTgke45iJcg+LCfwM8oTw1WRwCV1eyDAAfY1T4bHHcZGifbD8YZA3OKdtCajEbaoy6CA cnow== X-Received: by 10.28.72.137 with SMTP id v131mr1739565wma.63.1448047798566; Fri, 20 Nov 2015 11:29:58 -0800 (PST) In-Reply-To: <564E6352.20701@cs.ucla.edu> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c09::229 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:194889 Archived-At: --001a114b6af6a6c34b0524fde607 Content-Type: text/plain; charset=UTF-8 Paul Eggert schrieb am Fr., 20. Nov. 2015 um 01:03 Uhr: > On 11/19/2015 03:57 PM, Philipp Stephani wrote: > > Thanks. I saw you changed some other members to ptrdiff_t (the public > > size members of emacs_runtime and emacs_env), is that intentional, and > > if so, what is the reason? > > As a general rule, in Emacs source code we prefer signed arithmetic to > unsigned, because the latter is so error prone when it comes to > comparisons. Also, signed arithmetic allows for better low-level > checking, e.g., with -fsanitize=undefined. (There are a few exceptions, > e.g., hash values, but they're relatively rare.) So the module > interface should encourage the use of signed integer arithmetic when > possible. > This is generally a good practice. However for the size members I think there's still a slight advantage in using size_t. This member will typically be used as follows: if (env->size >= sizeof *env) { // good, object is at least as big as expected } else { // Emacs is too old } The return type of sizeof is size_t. Using ptrdiff_t for the size member means that this is now a comparison between types of different signedness. Such comparisons are rather subtle, and compilers warn about them (e.g. clang with -Wextra). So I'd suggest th avoid such comparisons. As we never do any arithmetic with the size members, the wrap-around behavior is not an issue in this case. > > It might also be useful to support modules that, for whatever reason, > cannot deal with signed integers and must use unsigned integers. That > could be something we add later, if necessary. > I think we always expect a reasonably standard C or C++ compiler, which has to support signed integers. > > > Anyway, emacs-module.h now lacks an #include . > > Thanks, fixed now. > --001a114b6af6a6c34b0524fde607 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Paul E= ggert <eggert@cs.ucla.edu> = schrieb am Fr., 20. Nov. 2015 um 01:03=C2=A0Uhr:
On 11/19/2015 03:57 PM, Philipp Stephani wrote:
> Thanks. I saw you changed some other members to ptrdiff_t (the public<= br> > size members of emacs_runtime and emacs_env), is that intentional, and=
> if so, what is the reason?

As a general rule, in Emacs source code we prefer signed arithmetic to
unsigned, because the latter is so error prone when it comes to
comparisons. Also, signed arithmetic allows for better low-level
checking, e.g., with -fsanitize=3Dundefined. (There are a few exceptions, e.g., hash values, but they're relatively rare.)=C2=A0 So the module interface should encourage the use of signed integer arithmetic when
possible.

This is generally a good prac= tice.
However for the size members I think there's still a sl= ight advantage in using size_t. This member will typically be used as follo= ws:

if (env->size >=3D sizeof *env) {
<= div>=C2=A0 // good, object is at least as big as expected
} else = {
=C2=A0 // Emacs is too old
}

The return type of sizeof is size_t. Using ptrdiff_t for the size member m= eans that this is now a comparison between types of different signedness. S= uch comparisons are rather subtle, and compilers warn about them (e.g. clan= g with -Wextra). So I'd suggest th avoid such comparisons. As we never = do any arithmetic with the size members, the wrap-around behavior is not an= issue in this case.
=C2=A0

It might also be useful to support modules that, for whatever reason,
cannot deal with signed integers and must use unsigned integers. That
could be something we add later, if necessary.

I think we always expect a reasonably standard C or C++ compiler, w= hich has to support signed integers.
=C2=A0

> Anyway, emacs-module.h now lacks an #include <stddef.h>.

Thanks, fixed now.
--001a114b6af6a6c34b0524fde607--