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 20:45:32 +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> <837fld6lps.fsf@gnu.org> <564F69F1.1030305@cs.ucla.edu> <564F8355.2070806@cs.ucla.edu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a114b07d47c70850524fef51b X-Trace: ger.gmane.org 1448052360 21483 80.91.229.3 (20 Nov 2015 20:46:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 20 Nov 2015 20:46:00 +0000 (UTC) Cc: aurelien.aptel+emacs@gmail.com, tzz@lifelogs.com, emacs-devel@gnu.org To: Paul Eggert , Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 20 21:45:59 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 1ZzsZ4-0002gz-Po for ged-emacs-devel@m.gmane.org; Fri, 20 Nov 2015 21:45:50 +0100 Original-Received: from localhost ([::1]:49797 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZzsZ4-0008Sk-3n for ged-emacs-devel@m.gmane.org; Fri, 20 Nov 2015 15:45:50 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39108) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZzsZ0-0008SP-06 for emacs-devel@gnu.org; Fri, 20 Nov 2015 15:45:46 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZzsYy-0001j2-Sy for emacs-devel@gnu.org; Fri, 20 Nov 2015 15:45:45 -0500 Original-Received: from mail-wm0-x231.google.com ([2a00:1450:400c:c09::231]:33204) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZzsYx-0001ic-2f; Fri, 20 Nov 2015 15:45:43 -0500 Original-Received: by wmec201 with SMTP id c201so88350568wme.0; Fri, 20 Nov 2015 12:45:42 -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=MR0M044BduQwtc9BObvcxFxgNM8e5/sScA4QIwJiD+8=; b=0jPjUL6S0p3uMVarsu9PHW8eTuuOWsDIHZDP45WNPwsTfJRkE97Zm7GtZdMwbJqBUD +raEa31r4SIlyY5Vidvot+E0Uw5/Iuv2IPLAn5Kcc6ZzayxHugmUYODctJhqj1H/ZTnb B1m60xQSssUDcxjuNC0I8L8QIT4DVsjgXAIlRllHHxQRZN2hHiLwPF57q+S+L1Pq3/x6 BXqqgHH2OUI+SnIeQRQyzFrlTkZN05lbsqaEuK4m2kQI1DJ9cB9uAARElGs93Q/LT/Gw 8KHMtnSaQ/ZZVhj2/kYHjFq14ju4dIyNzxGg0ICEQ01GvixzZCKLuzYZ6y/L12BFmnuU AKkQ== X-Received: by 10.28.187.4 with SMTP id l4mr1900089wmf.33.1448052342417; Fri, 20 Nov 2015 12:45:42 -0800 (PST) In-Reply-To: <564F8355.2070806@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::231 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:194896 Archived-At: --001a114b07d47c70850524fef51b Content-Type: text/plain; charset=UTF-8 Paul Eggert schrieb am Fr., 20. Nov. 2015 um 21:32 Uhr: > Philipp Stephani wrote: > > Daniel felt pretty strongly about using int64 for fixnums. > > As I recall, he felt that we shouldn't use EMACS_INT in the module API, and > int64_t was merely a means to that goal. If so, that's not a reason to > prefer > int64_t over intmax_t; it's merely a reason to make sure that intmax_t is > at > least as portable as int64_t is in this area. Which it is. > > > Is there any reason to change that? > > Yes, int64_t is not required by POSIX, C99, etc. That is, int64_t is an > optional type. In contrast, intmax_t is required on all C99 platforms, > and it > has better support (e.g., there's a printf format specifier for it), so > there > are advantages to intmax_t over int64_t. I don't know of any advantage > int64_t > would have over intmax_t on any platform that Emacs supports. > It would be guaranteed to always have the same size, if available. My understanding is that intmax_t could differ between compilers even on the same machine, which would silently break compatibility. --001a114b07d47c70850524fef51b 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 21:32=C2=A0Uhr:
Philipp Stephani wrote:
> Daniel felt pretty strongly about using int64 for fixnums.

As I recall, he felt that we shouldn't use EMACS_INT in the module API,= and
int64_t was merely a means to that goal. If so, that's not a reason to = prefer
int64_t over intmax_t; it's merely a reason to make sure that intmax_t = is at
least as portable as int64_t is in this area. Which it is.

=C2=A0> Is there any reason to change that?

Yes, int64_t is not required by POSIX, C99, etc.=C2=A0 That is, int64_t is = an
optional type.=C2=A0 In contrast, intmax_t is required on all C99 platforms= , and it
has better support (e.g., there's a printf format specifier for it), so= there
are advantages to intmax_t over int64_t.=C2=A0 I don't know of any adva= ntage int64_t
would have over intmax_t on any platform that Emacs supports.

It would be guaranteed to always have the same size,= if available. My understanding is that intmax_t could differ between compi= lers even on the same machine, which would silently break compatibility.=C2= =A0
--001a114b07d47c70850524fef51b--