From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: JSON/YAML/TOML/etc. parsing performance Date: Tue, 03 Oct 2017 20:10:18 +0300 Message-ID: <83wp4cyx6t.fsf@gnu.org> 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> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1507050676 27705 195.159.176.226 (3 Oct 2017 17:11:16 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 3 Oct 2017 17:11:16 +0000 (UTC) Cc: emacs-devel@gnu.org To: p.stephani2@gmail.com, Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 03 19:11: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 1dzQit-0006nF-CY for ged-emacs-devel@m.gmane.org; Tue, 03 Oct 2017 19:11:11 +0200 Original-Received: from localhost ([::1]:59574 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dzQj0-0005oX-MR for ged-emacs-devel@m.gmane.org; Tue, 03 Oct 2017 13:11:18 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54821) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dzQiN-0005oH-A5 for emacs-devel@gnu.org; Tue, 03 Oct 2017 13:10:40 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dzQiI-0002gJ-BR for emacs-devel@gnu.org; Tue, 03 Oct 2017 13:10:39 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:36938) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dzQiI-0002g4-7i; Tue, 03 Oct 2017 13:10:34 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3032 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dzQiH-000780-Kz; Tue, 03 Oct 2017 13:10:34 -0400 In-reply-to: <837ewc19ki.fsf@gnu.org> (message from Eli Zaretskii on Tue, 03 Oct 2017 19:26:53 +0300) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:219044 Archived-At: > 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. Paul, can you please comment on this? Thanks.