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: Dynamic loading progress Date: Sun, 4 Oct 2015 12:20:46 -0700 Organization: UCLA Computer Science Department Message-ID: <56117C0E.2050206@cs.ucla.edu> References: <87bnl1vmqf.fsf@lifelogs.com> <87vbj8tow4.fsf@lifelogs.com> <87r3twtagf.fsf@lifelogs.com> <85siebl7ws.fsf@stephe-leake.org> <85a90ilwmm.fsf@stephe-leake.org> <83386a6f7z.fsf@gnu.org> <85h9upjz7v.fsf@stephe-leake.org> <83wq3k3kl4.fsf@gnu.org> <85bnkwil1c.fsf@stephe-leake.org> <83pp9cwky8.fsf@gnu.org> <85a90ggf2d.fsf@stephe-leake.org> <54E0A40F.5080603@dancol.org> <83sie7un20.fsf@gnu.org> <54E0D181.2080802@dancol.org> <83r3trulse.fsf@gnu.org> <54E0D7E0.305@[87.69.4.28]> <83h9unukbg.fsf@gnu.org> <54E0DEF8.7020901@dancol> <83egpruiyp.fsf@gnu.org> <54E0FF93.2000104@dancol.org> <5610ED13.1010406@dancol.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1443986501 26085 80.91.229.3 (4 Oct 2015 19:21:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 4 Oct 2015 19:21:41 +0000 (UTC) Cc: =?UTF-8?Q?Aur=c3=a9lien_Aptel?= , stephen_leake@stephe-leake.org, emacs-devel@gnu.org To: Philipp Stephani , Daniel Colascione , Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Oct 04 21:21:33 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 1Zioqi-0004cw-7a for ged-emacs-devel@m.gmane.org; Sun, 04 Oct 2015 21:21:32 +0200 Original-Received: from localhost ([::1]:43467 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zioqh-0007EC-KS for ged-emacs-devel@m.gmane.org; Sun, 04 Oct 2015 15:21:31 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36475) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZioqC-0006tj-Cj for emacs-devel@gnu.org; Sun, 04 Oct 2015 15:21:01 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZioqB-0007AI-JX for emacs-devel@gnu.org; Sun, 04 Oct 2015 15:21:00 -0400 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:54768) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zioq7-00078C-2b; Sun, 04 Oct 2015 15:20:55 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 90D461601E6; Sun, 4 Oct 2015 12:20:52 -0700 (PDT) Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id JmOsBQlhrSVi; Sun, 4 Oct 2015 12:20:51 -0700 (PDT) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id DB3C4160E83; Sun, 4 Oct 2015 12:20:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id fZeLQRH2BKF1; Sun, 4 Oct 2015 12:20:51 -0700 (PDT) Original-Received: from [192.168.1.9] (pool-100-32-155-148.lsanca.fios.verizon.net [100.32.155.148]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 7B6201601E6; Sun, 4 Oct 2015 12:20:50 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 131.179.128.68 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:190897 Archived-At: Philipp Stephani wrote: >> Why make the behavior vary depending on what intmax_t is? At least >> >int64_t is nice and explicit. >> > >> > > True. The time when Emacs integers will be larger than 64 bits is probably > far in the future. No, I've already been toying with integers wider than 64 bits in my own private copy of emacs. It's not ready for publication yet, but you should be assuming that bignums are possible and even desirable, and foreign-function APIs should not preclude their use. Also, the C standard does not require support for int64_t. It's OK to use int64_t in platform-specific code where you know the platform has int64_t, but otherwise it's better to avoid it. The Emacs source code largely avoids int64_t now, and there's no good reason to require it here.