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: Sun, 8 Oct 2017 23:22:01 -0700 Organization: UCLA Computer Science Department Message-ID: <37e197d2-ba2f-966f-18ff-53fa6c108bda@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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1507530158 29893 195.159.176.226 (9 Oct 2017 06:22:38 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 9 Oct 2017 06:22:38 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 Cc: emacs-devel@gnu.org To: Philipp Stephani , Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 09 08:22:35 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 1e1RSU-00076B-E6 for ged-emacs-devel@m.gmane.org; Mon, 09 Oct 2017 08:22:34 +0200 Original-Received: from localhost ([::1]:56314 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e1RSb-0004XP-MU for ged-emacs-devel@m.gmane.org; Mon, 09 Oct 2017 02:22:41 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47020) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e1RS3-0004XH-Lh for emacs-devel@gnu.org; Mon, 09 Oct 2017 02:22:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e1RS2-0008H3-Sy for emacs-devel@gnu.org; Mon, 09 Oct 2017 02:22:07 -0400 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:50264) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1e1RRz-0008Ed-4G; Mon, 09 Oct 2017 02:22:03 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 4F3E61601F6; Sun, 8 Oct 2017 23:22:02 -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 Jrw0__g70qTD; Sun, 8 Oct 2017 23:22:01 -0700 (PDT) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 9364D160D38; Sun, 8 Oct 2017 23:22:01 -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 3a3T2BUoDzN7; Sun, 8 Oct 2017 23:22:01 -0700 (PDT) Original-Received: from [192.168.1.9] (unknown [47.154.18.85]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 748081601F6; Sun, 8 Oct 2017 23:22:01 -0700 (PDT) In-Reply-To: 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:219287 Archived-At: Philipp Stephani wrote: > Should I at least add an eassert to document this? I wouldn't. Many calls to memory allocators would have problems if they r= equest=20 more than PTRDIFF_MAX bytes, given the problems that C programs have when= doing=20 pointer arithmetic on large objects. It would be a waste of time to docum= ent=20 this in every call by doing an eassert. Simply calling a memory allocator= that=20 is documented to not return such objects, should make it clear to the rea= der=20 what is going on. > I've attached a new patch (which currently segfaults on > decode_coding_gap, but the call to that function doesn't seem to be > required anyway). Thanks, I plan to take a look at it after the decode_coding_gap issue is = addressed.