From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: JSON/YAML/TOML/etc. parsing performance Date: Fri, 6 Oct 2017 12:36:17 -0700 Organization: UCLA Computer Science Department Message-ID: References: <87poaqhc63.fsf@lifelogs.com> <8360ceh5f1.fsf@gnu.org> <83h8vl5lf9.fsf@gnu.org> <83r2um3fqi.fsf@gnu.org> <43520b71-9e25-926c-d744-78098dad6441@cs.ucla.edu> <83o9pnzddc.fsf@gnu.org> <472176ce-846b-1f24-716b-98eb95ceaa47@cs.ucla.edu> <83d163z6dy.fsf@gnu.org> <73477c99-1600-a53d-d84f-737837d0f91f@cs.ucla.edu> <83poa2ya8j.fsf@gnu.org> <21b0ba97-ed49-43ae-e86f-63fba762353a@cs.ucla.edu> <83lgkqxe3l.fsf@gnu.org> <83376wwwol.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1507318627 9444 195.159.176.226 (6 Oct 2017 19:37:07 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 6 Oct 2017 19:37:07 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 Cc: p.stephani2@gmail.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 06 21:37:03 2017 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 1e0YQf-0001nW-Hg for ged-emacs-devel@m.gmane.org; Fri, 06 Oct 2017 21:37:01 +0200 Original-Received: from localhost ([::1]:46896 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e0YQm-0003km-Np for ged-emacs-devel@m.gmane.org; Fri, 06 Oct 2017 15:37:08 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39717) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e0YQB-0003kc-9p for emacs-devel@gnu.org; Fri, 06 Oct 2017 15:36:32 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e0YQA-00089j-C9 for emacs-devel@gnu.org; Fri, 06 Oct 2017 15:36:31 -0400 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:59764) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1e0YQ5-00081x-O0; Fri, 06 Oct 2017 15:36:25 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 8153C160E14; Fri, 6 Oct 2017 12:36:23 -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 HV4noDd5Jnt5; Fri, 6 Oct 2017 12:36:22 -0700 (PDT) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id C0DC6160E51; Fri, 6 Oct 2017 12:36:22 -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 Vdj0Wk2S65dt; Fri, 6 Oct 2017 12:36:22 -0700 (PDT) Original-Received: from Penguin.CS.UCLA.EDU (Penguin.CS.UCLA.EDU [131.179.64.200]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id A428E160E14; Fri, 6 Oct 2017 12:36:22 -0700 (PDT) In-Reply-To: <83376wwwol.fsf@gnu.org> Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 131.179.128.68 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:219209 Archived-At: On 10/06/2017 12:40 AM, Eli Zaretskii wrote: > Those valid-but-enormous values are either invalid (if they are larger > than PTRDIFF_MAX), or easily uncovered by looking at higher call-stack > frames in the debugger I'm not quite following, since "valid-but-enormous values" cannot be invalid. However, I don't normally use a debugger to find or debug integer-overflow problems. I more often use static analysis, for which signed integers work better since static analysis can more-easily detect signed operations that look dubious. When I do run-time checking, I normally use -fsanitize=undefined or something like that, instead of GDB; and here again, signed integers work better than unsigned integers do. > I don't envision many primitives to need this kind of change At present zero primitives need this kind of change for JSON, since the JSON code doesn't need to do any overflow checking for sizes under the currently-proposed patches. If we run across the problem in the future for other libraries, we can revisit the issue then. > I'm not sure that experience is 100% applicable to Emacs, because > Emacs has special needs due to the fact that our integers are narrower > than the corresponding C integral types. That problem is separate from the ptrdiff_t vs size_t problem, which is the issue at hand here, and which corresponds directly to the experience I've had with with ptrdiff_t and size_t in other GNU programs. Preferring ptrdiff_t to size_t (or vice versa) does not affect whether code needs to check for fixnum overflow.