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: Wed, 4 Oct 2017 14:24:59 -0700 Organization: UCLA Computer Science Department Message-ID: <21b0ba97-ed49-43ae-e86f-63fba762353a@cs.ucla.edu> 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> 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 1507152316 24651 195.159.176.226 (4 Oct 2017 21:25:16 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 4 Oct 2017 21:25:16 +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 Wed Oct 04 23:25:12 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 1dzrAF-0005W3-JV for ged-emacs-devel@m.gmane.org; Wed, 04 Oct 2017 23:25:11 +0200 Original-Received: from localhost ([::1]:36901 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dzrAJ-0001Vg-0G for ged-emacs-devel@m.gmane.org; Wed, 04 Oct 2017 17:25:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54611) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dzrAA-0001Vb-3s for emacs-devel@gnu.org; Wed, 04 Oct 2017 17:25:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dzrA9-00076Z-5U for emacs-devel@gnu.org; Wed, 04 Oct 2017 17:25:06 -0400 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:52916) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dzrA5-00072t-Hn; Wed, 04 Oct 2017 17:25:01 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 2EEFC16011A; Wed, 4 Oct 2017 14:25:00 -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 Uh1yGH08JYpU; Wed, 4 Oct 2017 14:24:59 -0700 (PDT) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 751EC160E29; Wed, 4 Oct 2017 14:24:59 -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 UrwT0Shf8OyQ; Wed, 4 Oct 2017 14:24:59 -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 5C4F916011A; Wed, 4 Oct 2017 14:24:59 -0700 (PDT) In-Reply-To: <83poa2ya8j.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:219092 Archived-At: On 10/04/2017 12:38 PM, Eli Zaretskii wrote: > if we did use size_t for the arguments which can clearly only be > non-negative, the problems which we are discussing would not have > happened Sure, but we would also have worse problems, as size_t is inherently more error-prone. ptrdiff_t overflows are reliably diagnosed when Emacs is compiled with suitable GCC compiler options. size_t overflows cannot be diagnosed, are all too common, and can cause serious trouble. The Emacs internals occasionally use size_t because underlying primitives like 'malloc' do, so we do make some exceptions. Perhaps there should be an exception here, for convenience with the JSON library. The code snippets I've seen so far in this thread are not enough context to judge whether an exception would be helpful in this case. Generally speaking, though, unsigned types should be avoided because they are more error-prone. This has long been the style in Emacs internals, and it's served us well. (Ironically, just last week I was telling beginning students to beware unsigned types, with (0u < -1) as an example....)