From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#70007: [PATCH] native JSON encoder Date: Sat, 30 Mar 2024 16:22:57 +0300 Message-ID: <86le5zdfbi.fsf@gnu.org> References: <1BF559D1-DB9F-4FEB-90ED-72E0EFD76424@gmail.com> <86wmpphrg7.fsf@gnu.org> <4589243D-C11A-45C1-AF3E-6F4A5BADEB54@gmail.com> <864jcrindg.fsf@gnu.org> <291DD5F1-85B8-4647-A40A-EBBD4C51E253@gmail.com> <8634sbijfx.fsf@gnu.org> <2CF47DA5-A65B-47C4-A28A-6FEE1469BD13@gmail.com> <86cyrdfuai.fsf@gnu.org> <3139C8FE-5C67-4FE3-B940-F449DA73E76C@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2034"; mail-complaints-to="usenet@ciao.gmane.io" Cc: casouri@gmail.com, 70007@debbugs.gnu.org To: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Mar 30 14:24:08 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1rqYgq-0000Ho-HS for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 30 Mar 2024 14:24:08 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rqYgj-0004GB-HT; Sat, 30 Mar 2024 09:24:01 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rqYgi-0004G3-Gl for bug-gnu-emacs@gnu.org; Sat, 30 Mar 2024 09:24:00 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rqYgi-0000RD-8J for bug-gnu-emacs@gnu.org; Sat, 30 Mar 2024 09:24:00 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rqYgk-0007sx-5H for bug-gnu-emacs@gnu.org; Sat, 30 Mar 2024 09:24:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 30 Mar 2024 13:24:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 70007 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 70007-submit@debbugs.gnu.org id=B70007.171180499230119 (code B ref 70007); Sat, 30 Mar 2024 13:24:02 +0000 Original-Received: (at 70007) by debbugs.gnu.org; 30 Mar 2024 13:23:12 +0000 Original-Received: from localhost ([127.0.0.1]:44203 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rqYfv-0007pi-MA for submit@debbugs.gnu.org; Sat, 30 Mar 2024 09:23:12 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38214) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rqYfs-0007pF-QE for 70007@debbugs.gnu.org; Sat, 30 Mar 2024 09:23:10 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rqYfl-0000Lr-7g; Sat, 30 Mar 2024 09:23:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=JJuw+ORI8zlhnvoIR7WneDY5qSTINoXJ1znBHt+RqZ0=; b=nQ51RTkW+ustSJ+YXq/P CBtrqjkBronKAd7CcrDNWmuUPSZILLAWwLv6MvucASQmVvg/Tl67bvHMWGFAEfzh/Ywd/EAC0+VoD oDGjW8DdxTxvfXVP2GsQYXwacKM+mQ4R3ihAh3rCXiy2XRlt9fMz68wcdjeB+WbdQCehwV4JrTEKk 6i1QiMTSx+IiNePtCd0iAYbN8ql+18X/Q7HgRc6wYR8SpimMI1gXfkfMl/cc1sHp/X/r6ZcSBGAVK exQ7Tt0yQZ3hLQ3VQJ1y5Gg4DIchWpyK5973Ya0nSQQyEu/3Iw/htnWLIX82WxB1ur7doxjtHBtZI 9am/nJibPI1ySg==; In-Reply-To: <3139C8FE-5C67-4FE3-B940-F449DA73E76C@gmail.com> (message from Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= on Sat, 30 Mar 2024 12:41:31 +0100) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:282363 Archived-At: > From: Mattias Engdegård > Date: Sat, 30 Mar 2024 12:41:31 +0100 > Cc: casouri@gmail.com, > 70007@debbugs.gnu.org > > 29 mars 2024 kl. 07.04 skrev Eli Zaretskii : > > > OK. FTR, I'm not in favor of validation of unibyte strings, I just > > suggest that we treat them as plain-ASCII: pass them through without > > any validation, leaving the validation to the callers. > > Actually we are more or less forced to validate unibyte strings as long as the serialiser returns multibyte. Which we agree that it probably shouldn't, but I'd first like to take some time to ensure that returning unibyte won't break anything. Yes, I was writing about the state of affairs when we change the serializer to emit unibyte strings. > Thank you for pushing the new JSON parser to master. I've rebased my patch and cleaned it up a bit, and it now removes all uses of Jansson from json.c. Since the change involves removing some Windows-specific code, perhaps you would like to check that it still compiles on that platform, if you have the time? It builds and passes the tests, thanks. But I have a couple of minor nits below. > +static struct symset_tbl * > +make_symset_table (int bits, struct symset_tbl *up) > +{ > + int maxbits = min (SIZE_WIDTH - 2 - (word_size < 8 ? 2 : 3), 32); > + if (bits > maxbits) > + error ("out of memory"); /* Will never happen in practice. */ This should be a call to memory_full, no? Or if we must signal this error here, at least make the error message more specific: mention JSON or somesuch. > +{ > + double x = XFLOAT_DATA (f); > + if (isinf (x) || isnan (x)) > + signal_error ("not a finite number", f); I'd prefer a more specific error message here, like JSON does not allow Inf or NaN Last, but not least: should we have a json-available-p function that always returns non-nil, for better backward-compatibility? Otherwise, code out there might decide to use json.elm which is not what we want.