From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.bugs Subject: bug#27270: display-raw-bytes-as-hex generates ambiguous output for Emacs strings Date: Sun, 24 Apr 2022 15:35:53 -0700 Organization: UCLA Computer Science Department Message-ID: <04ac11a4-91a6-00f9-1a12-07e5f62b46b4@cs.ucla.edu> References: <29d6844f-2f6f-11c1-7877-a9d169e613f8@cs.ucla.edu> <83tw3s8jhr.fsf@gnu.org> <1c05b888-0c4a-05c8-248a-6e550637fff4@cs.ucla.edu> <8737bbxp6a.fsf@users.sourceforge.net> <2d5a8cd8-0884-bc1e-4298-a84dca61acbf@cs.ucla.edu> <831squ8no8.fsf@gnu.org> <93d9c575-4eb2-ea9e-d998-a8f3cff33a1e@cs.ucla.edu> <83y3t271ar.fsf@gnu.org> <83shja6yoq.fsf@gnu.org> <83r2yt7lad.fsf@gnu.org> <2202b54b-606f-0a10-abf7-5cb1a9164897@cs.ucla.edu> <87k0bfsxvk.fsf@gnus.org> <87sfq2d8qi.fsf@gnus.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35273"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Cc: v.schneidermann@gmail.com, 27270@debbugs.gnu.org, npostavs@users.sourceforge.net To: Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Apr 25 00:37:14 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 1nikqv-00092E-T0 for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 25 Apr 2022 00:37:13 +0200 Original-Received: from localhost ([::1]:44820 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nikqu-0005g2-LD for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 24 Apr 2022 18:37:12 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53208) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nikqk-0005dE-Vc for bug-gnu-emacs@gnu.org; Sun, 24 Apr 2022 18:37:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:38169) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nikqk-00060o-N9 for bug-gnu-emacs@gnu.org; Sun, 24 Apr 2022 18:37:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nikqk-0005tF-Fu for bug-gnu-emacs@gnu.org; Sun, 24 Apr 2022 18:37:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 24 Apr 2022 22:37:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 27270 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo Original-Received: via spool by 27270-submit@debbugs.gnu.org id=B27270.165083976322562 (code B ref 27270); Sun, 24 Apr 2022 22:37:02 +0000 Original-Received: (at 27270) by debbugs.gnu.org; 24 Apr 2022 22:36:03 +0000 Original-Received: from localhost ([127.0.0.1]:60299 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nikpm-0005rq-TF for submit@debbugs.gnu.org; Sun, 24 Apr 2022 18:36:03 -0400 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:52312) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nikpl-0005rL-2q for 27270@debbugs.gnu.org; Sun, 24 Apr 2022 18:36:01 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 4119316009A; Sun, 24 Apr 2022 15:35:55 -0700 (PDT) Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id EkPUDYMCFffU; Sun, 24 Apr 2022 15:35:54 -0700 (PDT) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 774CD1600C5; Sun, 24 Apr 2022 15:35:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id wj4t7T7jOZKt; Sun, 24 Apr 2022 15:35:54 -0700 (PDT) Original-Received: from [192.168.1.9] (cpe-172-91-119-151.socal.res.rr.com [172.91.119.151]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 3EAAD16009A; Sun, 24 Apr 2022 15:35:54 -0700 (PDT) Content-Language: en-US In-Reply-To: <87sfq2d8qi.fsf@gnus.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:230595 Archived-At: On 4/24/22 04:24, Lars Ingebrigtsen wrote: > The likelihood of anybody actually encountering this issue is ... small. Sure, if strings are random. But strings from opponents aren't random. I'll readily grant that it's a much smaller exposure than SQL injection. Still, like SQL injection it's an exposure and should be fixed. > You want to quote all %c as if they were raw bytes? Or only following a > raw byte? Closer to the latter, but even less than the latter. I am being conservative and am proposing that Emacs do what it does now unless the resulting output would be misinterpreted on input. So I wouldn't change how all characters are quoted; only how characters are quoted when the result would be interpreted incorrectly. > what about (format "%cf" #x9e) Since that returns a multibyte string, I suggest "\u009ef" which is multibyte. For its unibyte counterpart (encode-coding-string (format "%cf" #x9e) 'iso-latin-1) I suggest the syntax "\x9e\ f" which is unibyte. (These are not the only possibilities; for example, the former could be "\u009e\ f" if you think that's clearer.) This string syntax is already supported by Emacs, so this wouldn't change the Lisp reader. > it creates > very confusing displayed strings. These examples are not *that* confusing. And although they may not be beautiful, correct strings are less confusing than incorrect strings.