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: Mon, 09 Oct 2017 09:47:16 +0300 Message-ID: <83k204stqj.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> <83poa2ya8j.fsf@gnu.org> <21b0ba97-ed49-43ae-e86f-63fba762353a@cs.ucla.edu> <83lgkqxe3l.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1507531704 24393 195.159.176.226 (9 Oct 2017 06:48:24 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 9 Oct 2017 06:48:24 +0000 (UTC) Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org To: Philipp Stephani Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 09 08:48:15 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 1e1RrK-0005ID-0v for ged-emacs-devel@m.gmane.org; Mon, 09 Oct 2017 08:48:14 +0200 Original-Received: from localhost ([::1]:56376 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e1RrR-0002Gp-IN for ged-emacs-devel@m.gmane.org; Mon, 09 Oct 2017 02:48:21 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51995) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e1Rqb-0002Fg-7l for emacs-devel@gnu.org; Mon, 09 Oct 2017 02:47:30 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e1RqW-0003k1-Az for emacs-devel@gnu.org; Mon, 09 Oct 2017 02:47:29 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:52212) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e1RqW-0003jv-7f; Mon, 09 Oct 2017 02:47:24 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4635 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1e1RqV-0001HJ-KJ; Mon, 09 Oct 2017 02:47:24 -0400 In-reply-to: (message from Philipp Stephani on Sun, 08 Oct 2017 23:04:10 +0000) 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:219289 Archived-At: > From: Philipp Stephani > Date: Sun, 08 Oct 2017 23:04:10 +0000 > Cc: emacs-devel@gnu.org > > If we were to change make_specified_string (and its subroutines, like > make_uninit_multibyte_string etc.) to accept a size_t value in its 3rd > argument, the need for the above check against PTRDIFF_MAX would > disappear. > > It wouldn't disappear, it would merely be shifted around. Arguments could be made for either choice, but > somewhere the check needs to happen. No, the need will entirely disappear, because make_uninit_multibyte_string already has a similar check, it just uses signed types for it currently. > It would also make the higher-level code more > reliable, because application-level programmers will not need to > understand all the non-trivial intricacies of this stuff. > > Every C programmer needs to understand these issues, no matter what codebase they are working with. I agree that it's very useful to understand these issues, but by requiring "every C programmer" to understand them, you are raising the bar for contributing to Emacs's C code considerably and IMO without any good reason. A C programmer for Emacs who needs to use primitives that create Lisp objects should expect those primitives to be safe, just like you expect libc function to be safe, once they pass the compilation with -Wall. > Lossy integral conversions are fundamental design choices of the C language that can't be avoided. They can and should be avoided on the level of jason.c, as long as the code itself doesn't do anything silly, which will then be flagged by the compiler. > C is a nasty language full of traps. I certainly disagree with that, having programmed in C for 35 years. > You can try to hide some of the traps, but you can't remove them. I want to hide them, as much as possible, from application-level code.