From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Philipp Stephani Newsgroups: gmane.emacs.devel Subject: Re: JSON/YAML/TOML/etc. parsing performance Date: Tue, 03 Oct 2017 18:37:57 +0000 Message-ID: References: <87poaqhc63.fsf@lifelogs.com> <8360ceh5f1.fsf@gnu.org> <83h8vl5lf9.fsf@gnu.org> <83r2um3fqi.fsf@gnu.org> <83fub01c4m.fsf@gnu.org> <837ewc19ki.fsf@gnu.org> <83wp4cyx6t.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a11408cbad42200055aa8cac6" X-Trace: blaine.gmane.org 1507056001 5799 195.159.176.226 (3 Oct 2017 18:40:01 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 3 Oct 2017 18:40:01 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii , Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 03 20:39:47 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 1dzS6b-00008i-5e for ged-emacs-devel@m.gmane.org; Tue, 03 Oct 2017 20:39:45 +0200 Original-Received: from localhost ([::1]:59849 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dzS6i-0004Hu-LQ for ged-emacs-devel@m.gmane.org; Tue, 03 Oct 2017 14:39:52 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54373) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dzS55-0003gJ-10 for emacs-devel@gnu.org; Tue, 03 Oct 2017 14:38:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dzS53-0003MJ-Ud for emacs-devel@gnu.org; Tue, 03 Oct 2017 14:38:11 -0400 Original-Received: from mail-oi0-x232.google.com ([2607:f8b0:4003:c06::232]:46293) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dzS52-0003Fe-CA; Tue, 03 Oct 2017 14:38:08 -0400 Original-Received: by mail-oi0-x232.google.com with SMTP id n82so8619650oig.3; Tue, 03 Oct 2017 11:38:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pp5/+K7UfrDPzh2xPDznzudh7HlhGP2Wy8QCZO0w6Vk=; b=WzGTbKXF0neCRq8X/H17sSa2X70yiaPKmxxxnmU83oD+fSu4QiObjSBrBzjbIbKoCE VmzytAd4XUPX+bffD3ikoPf2BP6gZKACm4V6ayJRjqccMQIYlWtVREzop8GJKQSKPQ1g cMwJvS12mdK31NQlrWZaCS4LcFrjoGy7S3JhiLL4GFBLyfcT9VB76jGW+TULEXv17o4W ZZCYYxFQ2CoVVLyg1N96aX3smd5ezoORPFv72JpDjPkd7K3ipF9eKW5089BYo410TAQD gy7MtkFxEnPI3YP/Vlwm4r2f58ksmTG7uxk2RFDYsRv7f5clc9x9awF/3WbWHvZJ3g/T QB3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pp5/+K7UfrDPzh2xPDznzudh7HlhGP2Wy8QCZO0w6Vk=; b=TSJr0JZdTXvDMftuqfYMSF7YMvF2C4H1KgrUpdZLs6eKzcYoDMDAMz7HVRXrxAQzE+ 1ViyxJODaDvvzfqsNlnlxu5ZJjEqTGROcrozYVVXJ8FzVg9NgOKxtchTPVW7YpIMmxPO 1jKqQkSX/1P21/yrSniIh0SgyhkkyxTzPmDfpuJ1Y51yeqBemQz7VYw3Ai4Wvlc33Skg kxVMpxHQNU60290d8U10y3xSO1lOWDO4ozJP8M0JMLOvDucUWJ2lCwHWCs6stNuV6s7a x+sXoIeuI7Yjg9R8B1MoIXRCwytb+7Ve0wE9wDgItED21gsNEkNm7xRDCR0K9etQpzga pB8A== X-Gm-Message-State: AHPjjUg9hZAsQp5R1UX9xtU/5q8NwbL1OVa+SxvY40orLnhX9WGXc9vP AXKuWThuuaY6vjLFq6rXIe7FKWyCdmsINzK/ng9VWg== X-Google-Smtp-Source: AOwi7QD2BwGBixXnSBOmYwwQw8H6Qp/DTDtCQCfrQYZC0c4j74O6FgH8Bq7kyrYmgvv0sKaS1LeKLH3zk5Hd3JgnaOI= X-Received: by 10.202.229.210 with SMTP id c201mr9034395oih.134.1507055887457; Tue, 03 Oct 2017 11:38:07 -0700 (PDT) In-Reply-To: <83wp4cyx6t.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4003:c06::232 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:219052 Archived-At: --001a11408cbad42200055aa8cac6 Content-Type: text/plain; charset="UTF-8" Eli Zaretskii schrieb am Di., 3. Okt. 2017 um 19:10 Uhr: > > Date: Tue, 03 Oct 2017 19:26:53 +0300 > > From: Eli Zaretskii > > Cc: emacs-devel@gnu.org > > > > > I don't understand why you think these checks aren't necessary. > Converting > > > between integral types when the number is out of range for the > destination > > > type results in an implementation-defined result, i.e. it's unportable. > > > > I'm saying that this code is the wrong place for doing these checks. > > We can discuss whether these checks are needed in general, and if we > > agree they are, we should change all the related allocation > > subroutines to do that there. > > Let me say this another way: Paul Eggert and others have spent the > last several years hardening Emacs primitives for all kinds of > infrequent situations where we could have undefined behavior. We now > have in many places dozens of tests and tricky macros we never had > before with checks and defenses against such calamities. If, after > all that, we still need application-level C code to do its own checks > for such situations, then I don't understand what we were doing all > these years, and why all the safety nets we added are not good enough > for taking care of this code as well. > > I'm certain those changes are useful! But they can't protect from data loss due to lossy type conversions; that is just a general behavior of C, and all C code needs to deal with it. --001a11408cbad42200055aa8cac6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Eli Za= retskii <eliz@gnu.org> schrieb am= Di., 3. Okt. 2017 um 19:10=C2=A0Uhr:
> Date: Tue, 03 Oct 2017 19:26:53 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-dev= el@gnu.org
>
> > I don't understand why you think these checks aren't nece= ssary. Converting
> > between integral types when the number is out of range for the de= stination
> > type results in an implementation-defined result, i.e. it's u= nportable.
>
> I'm saying that this code is the wrong place for doing these check= s.
> We can discuss whether these checks are needed in general, and if we > agree they are, we should change all the related allocation
> subroutines to do that there.

Let me say this another way: Paul Eggert and others have spent the
last several years hardening Emacs primitives for all kinds of
infrequent situations where we could have undefined behavior.=C2=A0 We now<= br> have in many places dozens of tests and tricky macros we never had
before with checks and defenses against such calamities.=C2=A0 If, after all that, we still need application-level C code to do its own checks
for such situations, then I don't understand what we were doing all
these years, and why all the safety nets we added are not good enough
for taking care of this code as well.


I'm certain those changes are usef= ul! But they can't protect from data loss due to lossy type conversions= ; that is just a general behavior of C, and all C code needs to deal with i= t.=C2=A0
--001a11408cbad42200055aa8cac6--