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 22:38:20 +0300 Message-ID: <83poa2ya8j.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> <83d163z6dy.fsf@gnu.org> <73477c99-1600-a53d-d84f-737837d0f91f@cs.ucla.edu> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1507145948 4632 195.159.176.226 (4 Oct 2017 19:39:08 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 4 Oct 2017 19:39:08 +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 21:39:04 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 1dzpVW-0000YU-UI for ged-emacs-devel@m.gmane.org; Wed, 04 Oct 2017 21:39:03 +0200 Original-Received: from localhost ([::1]:36596 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dzpVe-0002Zk-3v for ged-emacs-devel@m.gmane.org; Wed, 04 Oct 2017 15:39:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52056) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dzpV6-0002Zc-P2 for emacs-devel@gnu.org; Wed, 04 Oct 2017 15:38:37 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dzpV3-0004qw-KC for emacs-devel@gnu.org; Wed, 04 Oct 2017 15:38:36 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:35674) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dzpV3-0004qg-Gp; Wed, 04 Oct 2017 15:38:33 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2333 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dzpV2-0008Eo-Tz; Wed, 04 Oct 2017 15:38:33 -0400 In-reply-to: <73477c99-1600-a53d-d84f-737837d0f91f@cs.ucla.edu> (message from Paul Eggert on Wed, 4 Oct 2017 10:51:33 -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:219087 Archived-At: > Cc: p.stephani2@gmail.com, emacs-devel@gnu.org > From: Paul Eggert > Date: Wed, 4 Oct 2017 10:51:33 -0700 > > We should not encourage more use of size_t within Emacs, as it's an > unsigned type and unsigned types have the problems I mentioned. But 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, and we could simply rely on our primitives to do those checks. So it sounds like by avoiding use of size_t in those cases, we are shooting ourselves in the foot, by making our code more complex, less readable, and less efficient. IOW, a net loss. Look how much more complex is the proposed code in json.c than it could have been: we could remove all the redundant checks and quite some code that supports them. So I'm questioning the total avoidance of size_t in our low-level code. Why not allow it in a few places where negative values are clearly mistakes/bugs, and so if they appear as large positive values, and are rejected as such, that's OK?