From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: Another ptrdiff_t Date: Mon, 23 Jul 2012 14:41:23 -0700 Organization: UCLA Computer Science Department Message-ID: <500DC503.6030601@cs.ucla.edu> References: <83a9yr244w.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1343079695 18620 80.91.229.3 (23 Jul 2012 21:41:35 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 23 Jul 2012 21:41:35 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jul 23 23:41:35 2012 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 1StQNf-0001Iq-W1 for ged-emacs-devel@m.gmane.org; Mon, 23 Jul 2012 23:41:32 +0200 Original-Received: from localhost ([::1]:57635 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1StQNf-0003gw-Cf for ged-emacs-devel@m.gmane.org; Mon, 23 Jul 2012 17:41:31 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:57979) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1StQNc-0003fo-OM for emacs-devel@gnu.org; Mon, 23 Jul 2012 17:41:29 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1StQNb-0006oE-GE for emacs-devel@gnu.org; Mon, 23 Jul 2012 17:41:28 -0400 Original-Received: from smtp.cs.ucla.edu ([131.179.128.62]:33917) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1StQNZ-0006mJ-Nw; Mon, 23 Jul 2012 17:41:25 -0400 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id D997839E800E; Mon, 23 Jul 2012 14:41:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Original-Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8gsKSQ3-AUjY; Mon, 23 Jul 2012 14:41:24 -0700 (PDT) Original-Received: from [192.168.1.4] (pool-108-23-119-2.lsanca.fios.verizon.net [108.23.119.2]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 10C6539E8007; Mon, 23 Jul 2012 14:41:24 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 In-Reply-To: <83a9yr244w.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 131.179.128.62 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:151827 Archived-At: On 07/22/2012 08:43 AM, Eli Zaretskii wrote: > Can we perhaps have some conventions regarding which integer types to > use in what situations? Sure, here's a first cut. Perhaps this sort of thing should be put into a comment in lisp.h? Or into a new file under admin/notes? ==== Here are some guidelines for use of integer types in the Emacs C source code. These guidelines sometimes give competing advice; common sense is advised. . Avoid arbitrary limits. For example, avoid 'int len = strlen (s);' unless S's length is required for other reasons to fit in 'int' range. . Do not assume that signed integer arithmetic wraps around on overflow. This is no longer true of Emacs porting targets: signed integer overflow has undefined behavior in practice, and can dump core or even cause earlier or later code to behave "illogically". Unsigned overflow does wrap around reliably. . Prefer signed types to unsigned, as code gets confusing when signed and unsigned types are combined. Many other guidelines assume that types are signed; in the rarer cases where unsigned types are needed, similar advice may apply to the unsigned counterparts (e.g., size_t instead of ptrdiff_t, or uintptr_t instead of intptr_t). . Prefer 'int' for Emacs character codes, in the range 0 .. 0x3FFFFF. . Prefer ptrdiff_t for sizes, i.e., for integers bounded by the maximum size of any individual C object or by the maximum number of elements in any C array. This is part of Emacs's general preference for signed types. Using ptrdiff_t limits objects to PTRDIFF_MAX bytes, but larger objects would cause trouble anyway since they would break pointer subtraction, so this does not impose an arbitrary limit. . Prefer intptr_t for internal representations of pointers, or for integers bounded only by the number of objects that can exist at any given time or by the total number of bytes that can be allocated. Currently Emacs sometimes uses other types when intptr_t would be better; fixing this is lower priority, as the code works as-is on Emacs's current porting targets. . Prefer EMACS_INT for representing values converted to or from Emacs Lisp fixnums, as fixnum arithmetic is based on EMACS_INT. . When representing a system value (such as a file size or a count of seconds since the Epoch), prefer the corresponding system type (e.g., off_t, time_t). Do not assume that a system type is signed, unless this assumption is known to be safe (e.g., although off_t must be signed, time_t need not be). . Prefer printmax_t for representing values that might be any signed integer value that can be printed, using a printf-family function. . Prefer intmax_t for representing values that might be any signed integer value. . In bitfields, prefer 'unsigned int' to 'int' when space is tight, as 'int' is less portable (it might be signed, and might not be). . Currently Emacs typically uses 'int', 1, and 0 for boolean values. It's OK to use 'bool', 'true', and 'false' instead, as this usage is now portable -- a Gnulib replacement is used on older platforms. Using 'bool' can make programs easier to read, and a bit faster. At some point we may change Emacs to prefer 'bool' to 'int' where either will do.