From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Tom Gillespie Newsgroups: gmane.emacs.bugs Subject: bug#55645: src/print.c; print_object changes make it impossible to compare elisp code across versions Date: Sun, 29 May 2022 14:03:11 -0700 Message-ID: References: <87zgj4biw7.fsf@gnus.org> <874k1b9ser.fsf@gnus.org> <874k1a54ap.fsf@gnus.org> <87o7zg1nut.fsf@gnus.org> <83v8tojrr5.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12851"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Lars Ingebrigtsen , 55645@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun May 29 23:04:33 2022 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 1nvQ5Q-00036A-Iy for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 29 May 2022 23:04:32 +0200 Original-Received: from localhost ([::1]:54244 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nvQ5P-0002Un-30 for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 29 May 2022 17:04:31 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44130) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nvQ4w-0002Ub-42 for bug-gnu-emacs@gnu.org; Sun, 29 May 2022 17:04:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:48136) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nvQ4v-000414-R9 for bug-gnu-emacs@gnu.org; Sun, 29 May 2022 17:04:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nvQ4v-0008So-NK for bug-gnu-emacs@gnu.org; Sun, 29 May 2022 17:04:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Tom Gillespie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 29 May 2022 21:04:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 55645 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo Original-Received: via spool by 55645-submit@debbugs.gnu.org id=B55645.165385821032492 (code B ref 55645); Sun, 29 May 2022 21:04:01 +0000 Original-Received: (at 55645) by debbugs.gnu.org; 29 May 2022 21:03:30 +0000 Original-Received: from localhost ([127.0.0.1]:42033 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nvQ4P-0008Rz-Gx for submit@debbugs.gnu.org; Sun, 29 May 2022 17:03:29 -0400 Original-Received: from mail-yb1-f172.google.com ([209.85.219.172]:44578) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nvQ4O-0008Rn-MY for 55645@debbugs.gnu.org; Sun, 29 May 2022 17:03:29 -0400 Original-Received: by mail-yb1-f172.google.com with SMTP id a64so5921314ybg.11 for <55645@debbugs.gnu.org>; Sun, 29 May 2022 14:03:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wC3S8v4gidIBBvRFXeomFTlCS69Y09Mhi5FjsxopoF4=; b=MLTG440KIWgHwfTJJCkyNzhGdZmfo5IMRoSVyqzq4TCweRrd7jsl1+lKnlCV+mAkQy k0Yx/Ox8W//9iZv1pdNTgDArLcv2HHQT2I7jLU0uSve32vaqegw4bAO8K0PygCDgU8qm Ki9cvY0K4CvOnlDeZwwfnd6GXEKyGUmNCijhGs7NCWIJIjSt9Zmyz5LGR6ziPl3jyVrV E9ZATWJLNj5RdLeGG1UlApeFFq5zrRjIdWK72tenTfcrXKCCzLGhvZJ2/VotcT3wW6gb lW06whjKcEajh1PVZ2kvmIPU6I4ZpPuEuGqH+i2wSP5X0mhr7tjHAmzL7kZF8EXPSbDZ DAdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wC3S8v4gidIBBvRFXeomFTlCS69Y09Mhi5FjsxopoF4=; b=V29WhKUp8k6Obr/VUuC+4D6w8hc2eE9psrEl9fOz/grPEfvK1q6oB6LWQM6w2Bn+hD RB3e5WcjWrRTxcwgzB9uKqg1Q6+A4xBhs0VujC1VwF2LnOQZeQh+WVCyGaaVGUnacSfJ N93ufeWV7nApYec6qS0q5TbC4/jwhJ50fia0anBtHSK9MBMjWRxa50ZZV7tB9TETlcg5 Ovlkgqum0OCo2DGfNWrqKVnhDzNwI35tnWSJhgd4mhsc2UhsrvSzl92jPQarslHkbZ0D WxnetAfgWYVeCxtobGfosNsB1MoSS5GFiDJ8EJ8Hec46YfYZWwe25zH+cTmSQLpAEe6w 97nA== X-Gm-Message-State: AOAM530+68XvvsSrmQlbcjnnSOKHGgq3ne0o4rSTmsIuPv/EdOkG9+a4 mHH/tjNmn9iA8pzcCvTyWz4iqpscw+dtP9/ahwE= X-Google-Smtp-Source: ABdhPJwlUMFRqqbrruchFWCvcjkZFQHJTogmyrfVwbj4BvkW2ffZl2Rxf8qBqYfQOo5ZTF98tV/UgY6dVgkCgSarTRU= X-Received: by 2002:a25:af4e:0:b0:655:c9a3:affb with SMTP id c14-20020a25af4e000000b00655c9a3affbmr21374994ybj.360.1653858202812; Sun, 29 May 2022 14:03:22 -0700 (PDT) In-Reply-To: <83v8tojrr5.fsf@gnu.org> 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" Xref: news.gmane.io gmane.emacs.bugs:233345 Archived-At: Hi Eli, I have included an example below, with some additional context. Best! Tom I'm using my own use case as an example, but I suspect that there are other users out there who may have similar use cases where stability of the printed representation of read code is important. Some examples from a quick search on github that will or could be affected by this (beyond my own). I only searched for cases matching my own involving secure-hash and prin1-to-string, but there are surely other cases that would be affected that I have not imagined. https://github.com/skeeto/elfeed/blob/162d7d545ed41c27967d108c04aa31f5a61c8e16/web/elfeed-web.el#L73-L75 https://github.com/mrmekon/snitch-el/blob/3b3e7f1bf612c4624764d1ec4b1a96e4d2850b05/snitch-timer.el#L164-L181 https://github.com/radian-software/straight.el/blob/af5437f2afd00936c883124d6d3098721c2d306c/straight.el#L5627 https://github.com/search?q=prin1-to-string+secure-hash&type=Code You can filter out some of the noise by adding the follow to the search -elfeed -orgstrap -quelpa -litable -xah-elisp-mode -subr.el The use case that I have is to store the checksum of a code block to make sure that it has not changed. The checksum needs to be invariant to changes in formatting e.g. whitespace and needs to be backward and forward compatible across Emacs versions. In order to compute the checksum I need a serialized representation of the code. Note when I say "compare" two pieces of elisp code, one of them may no longer be available to be read, because only a checksum was retained, so direct comparison of the two structures in memory is not possible and defeats the point of having something that is simple to audit and store. This is discussed in more detail in the orgstrap readme. https://github.com/tgbugs/orgstrap/blob/master/README.org#normalization-functions https://github.com/tgbugs/orgstrap/blob/master/README.org#specification >From Emacs 18 through 28 prin1-to-string and the existing print variables have been able to provide the needed stability. There is currently no way to compensate for the change introduced in 637dde4aba921435f78d0de769ad74c4f3230aa6 short of reimplementing the old behavior of prin1-to-string from scratch, which would ultimately increase the maintenance load across the whole community. The example below works on emacs-18 (had to remove the number 1.0 example because emacs 18 does not have support for reading floats). The output of this code is unchanged from emacs-18 through emacs-28, however it is now different in emacs-29. Emacs 18-28: "(progn (+ 1 2) (a b\\.c d) (defun hello nil world)) (progn (some elisp code I want to normalize\\. That has strings \"1.0\" and symbols a\\.b))" Emacs 29: "(progn (+ 1 2) (a b.c d) (defun hello nil world)) (progn (some elisp code I want to normalize. That has strings \"1.0\" and symbols a.b))" #+begin_src elisp :tangle /tmp/example.el (defun normalize-elisp-code (body) (let (print-quoted print-length print-level) ; proposed variable would be added here (prin1-to-string (read (concat "(progn\n" body "\n)"))))) (defvar example-body-1 "(+ 1 2) (a b\\.c d) (defun hello () world)") (defvar example-body-2 (prin1-to-string '(some elisp code I want to normalize\. That has strings "1.0" and symbols a\.b))) (message "%s %s" (normalize-elisp-code example-body-1) (normalize-elisp-code example-body-2)) #+end_src The additional step in my use case is the checksum, which cannot be read back in, and changes from 28 -> 29 due to the differences in the output of prin1-to-string seen above. #+begin_src elisp (defun checksum-elisp-code (body) (secure-hash 'sha256 (normalize-elisp-code body))) (message "%s %s" (checksum-elisp-code example-body-1) (checksum-elisp-code example-body-2)) #+end_src