From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Karl Fogel Newsgroups: gmane.emacs.devel Subject: Some vars now limited to fixnum size. (Was: Merging bignum to master) Date: Mon, 20 Aug 2018 11:28:45 -0500 Message-ID: <878t51t32a.fsf_-_@red-bean.com> References: <877ekwu1mn.fsf@tromey.com> <611579fd-52f2-0104-ef82-a7a4a3929700@cs.ucla.edu> Reply-To: Karl Fogel NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1534782420 15879 195.159.176.226 (20 Aug 2018 16:27:00 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 20 Aug 2018 16:27:00 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: tom@tromey.com, Pip Cet , emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 20 18:26:56 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1frn13-0003yc-WB for ged-emacs-devel@m.gmane.org; Mon, 20 Aug 2018 18:26:54 +0200 Original-Received: from localhost ([::1]:48117 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1frn3A-0003qW-99 for ged-emacs-devel@m.gmane.org; Mon, 20 Aug 2018 12:29:04 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35131) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1frn31-0003qQ-BE for emacs-devel@gnu.org; Mon, 20 Aug 2018 12:28:56 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1frn2v-0004NG-4p for emacs-devel@gnu.org; Mon, 20 Aug 2018 12:28:53 -0400 Original-Received: from mail-yw1-xc34.google.com ([2607:f8b0:4864:20::c34]:43657) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1frn2u-0004LN-Un for emacs-devel@gnu.org; Mon, 20 Aug 2018 12:28:49 -0400 Original-Received: by mail-yw1-xc34.google.com with SMTP id l189-v6so7032588ywb.10 for ; Mon, 20 Aug 2018 09:28:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:subject:references:reply-to:date:in-reply-to :message-id:user-agent:mime-version; bh=VcJH/r1p3I9ilADxWiJbbfXxMdEzU8aqknawmKATqU8=; b=QVPVI5Nlezd7YbtbO6VYZMasFckzmD7A88yxa+drU1pjMFHzsvoo4Oppfdz5LfLYMX Wdt9Eku0sv0TJE8pynjWUc8AZxhe9okumlMTahN3qGY1DPBoaiIUcbR9JpoGYfmtPcZX Q1H7LoRUem6HzNR4zIOCgWbdRJZK08ZoTRe3fu66Wxi2CGqoWkfzxAU5M222kAwX+NS7 bOgh7PqI2jTgb8HuoEBwGU59NLiLEccKl6kxdcimbDClJTV9HDpYZ+cFlRwqF2b5YE9w bDXJCpscY2X0ALjwzr8GISrkm2woBuo/I1hrPBmza/Ivc/D9gV6p53LBuuQ54vY+xUaY BDQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:references:reply-to :date:in-reply-to:message-id:user-agent:mime-version; bh=VcJH/r1p3I9ilADxWiJbbfXxMdEzU8aqknawmKATqU8=; b=SpQWxCgD9XBQJobNaAcHM3coeHRv6KptLXCq+AMYVk3mWnuz/AkMJxQOUikWjwLGI6 vkYUpjhB9GXjXzw1SMGwqPmKSj2GyBGgnUcg8uj1jBHUeuESlMG7Crn6DVo4HsiaPtM2 IBNWMC/VPEi9CEMr6GHjJG58eGo6bjpg4TF9TBLE/ZvfrITfDoJImkpOSAxUTXMHw/ze 1zIDk+9zUKes+ZSFGJp8av4FZU7KyZxcIK524g0Nj7z0DYEIZHTDRs1llFOkOU8kzLh7 oJ+2ZRG1CeMNIg/V2mKdE5/lnGmj5uXXR3DhcrfX1GQKpMDLiHYAhYneAEZxWX5VTM1b xxxw== X-Gm-Message-State: AOUpUlHY6W+XH2yg1tnprKZ2r5GiunaTwpBheRb2l7/WDnm6ZMG980Vx yiVrCvwC7L5O01SB/P8DZXsBKBy+ X-Google-Smtp-Source: AA+uWPxI/Sy62KsWdlgF8lR62JDtt+0NnxGPG6IvPhIWy5Ht+tdCVe4Hsq9eDfzaOH0UMOgWmoQUzw== X-Received: by 2002:a81:7283:: with SMTP id n125-v6mr24261741ywc.63.1534782526870; Mon, 20 Aug 2018 09:28:46 -0700 (PDT) Original-Received: from kwork (74-92-190-114-Illinois.hfc.comcastbusiness.net. [74.92.190.114]) by smtp.gmail.com with ESMTPSA id 126-v6sm5377943ywl.48.2018.08.20.09.28.45 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 20 Aug 2018 09:28:46 -0700 (PDT) In-Reply-To: (Paul Eggert's message of "Tue, 14 Aug 2018 11:01:41 -0700") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::c34 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:228742 Archived-At: On 'master' as of commit ecd7a94077, if you do this: (setq mark-ring-max (1+ most-positive-fixnum)) then any command that calls `push-mark' will raise an error: Wrong type argument: fixnump, 2305843009213693952 (Lots of common commands do, obviously: `beginning-of-buffer', `yank', etc.) The root cause is in `nthcdr', which now requires a fixnum for its first argument, although this requirement is not documented: DEFUN ("nthcdr", Fnthcdr, Snthcdr, 2, 2, 0, doc: /* Take cdr N times on LIST, return the result. */) (Lisp_Object n, Lisp_Object list) { CHECK_FIXNUM (n); [...] } Should we document this? I haven't followed the fixnum thread(s) carefully -- has the issue of documenting fixnum requirements has already been raised and settled? My proposal would be to at least document it for `nthcdr', so that anyone who traces down the documentation stack down from this backtrace can see what happened without having to look at the C source code itself. I don't know how many other primitives are affected, but `nthcdr' seems like a major one. However, if this has already been discussed, and we've decided that fixnum is a reasonable requirement for many functions, and does not need to be documented specially, then that's fine. (As to why I was setting `mark-ring-max' so high as to run into this issue, that's a long story and not relevant here :-) .) Best regards, -Karl Paul Eggert writes: >Pip Cet wrote: >> Is it intentional that int-forwarded variables are still limited to >> the fixnum range? In any case, we probably didn't want to rename >> XINTFWD to XFIXNUMFWD... > >I think some C code does assume fixnum ranges for these variables, and >would have to be inspected. Presumably we'd go to either intmax_t >range or Emacs integers (fixnums or bignums), and that might need to >be thought through in a case-by-case basis. In the meantime XFIXNUMFWD >is probably a good name since that's effectively what the code does >now.