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: Wed, 04 Oct 2017 11:03:53 +0300 Message-ID: <83d163z6dy.fsf@gnu.org> 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> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1507104269 15383 195.159.176.226 (4 Oct 2017 08:04:29 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 4 Oct 2017 08:04:29 +0000 (UTC) Cc: p.stephani2@gmail.com, emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Oct 04 10:04:21 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 1dzefB-0002rS-T7 for ged-emacs-devel@m.gmane.org; Wed, 04 Oct 2017 10:04:18 +0200 Original-Received: from localhost ([::1]:33605 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dzefJ-0001hw-2n for ged-emacs-devel@m.gmane.org; Wed, 04 Oct 2017 04:04:25 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38883) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dzef4-0001hO-Ir for emacs-devel@gnu.org; Wed, 04 Oct 2017 04:04:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dzef1-0001ww-Fj for emacs-devel@gnu.org; Wed, 04 Oct 2017 04:04:10 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:51567) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dzef1-0001wY-C4; Wed, 04 Oct 2017 04:04:07 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3718 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dzef0-0005VL-Fo; Wed, 04 Oct 2017 04:04:07 -0400 In-reply-to: <472176ce-846b-1f24-716b-98eb95ceaa47@cs.ucla.edu> (message from Paul Eggert on Tue, 3 Oct 2017 23:41:41 -0700) 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:219064 Archived-At: > Cc: p.stephani2@gmail.com, emacs-devel@gnu.org > From: Paul Eggert > Date: Tue, 3 Oct 2017 23:41:41 -0700 > > Eli Zaretskii wrote: > > I'd prefer to have such tests inside 'insert' and its subroutines, or > > to tweak the argument passed to 'insert' to have the existing checks > > catch the problem. Can we do that, please? It doesn't feel right to > > me to have this kind of checks in application C code. > > There is no universal C integer type, so this doesn't sound doable in general. > Even intmax_t is not wide enough, as it doesn't subsume uintmax_t. And I > wouldn't want APIs to switch to intmax_t or uintmax_t merely because some > library's types don't match ours; the responsibility for passing arguments > correctly and for checking for any out-of-range values belongs to the glue code, > not to Emacs internals. That sounds very uncool, since many libraries use size_t, which means we will have to spread these checks for extremely rare cases all over our code, thus making it harder to read and maintain, and making it slower for no good reason. E.g., I see several uses of size_t in gnutls.c and in image.c, and at least some of them seem to be of the same nature as what was discussed here. Why didn't we add similar checks there?