From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs,gmane.emacs.devel Subject: bug#55719: [PATCH] bindat strz fixes Date: Wed, 01 Jun 2022 22:52:28 -0400 Message-ID: References: <6b1670d3-ae69-7f95-0e7d-d7cee0763c4a@rhansen.org> Reply-To: Stefan Monnier Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31473"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: 55719@debbugs.gnu.org, emacs-devel@gnu.org To: Richard Hansen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Jun 02 04:53:20 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 1nwaxb-0007yo-H3 for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 02 Jun 2022 04:53:19 +0200 Original-Received: from localhost ([::1]:40516 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nwaxa-0006RC-28 for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 01 Jun 2022 22:53:18 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37396) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nwaxL-0006PH-M3 for bug-gnu-emacs@gnu.org; Wed, 01 Jun 2022 22:53:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:58372) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nwaxK-00023h-Ek for bug-gnu-emacs@gnu.org; Wed, 01 Jun 2022 22:53:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nwaxK-0003QU-Bg for bug-gnu-emacs@gnu.org; Wed, 01 Jun 2022 22:53:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 02 Jun 2022 02:53:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 55719 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 55719-submit@debbugs.gnu.org id=B55719.165413836013135 (code B ref 55719); Thu, 02 Jun 2022 02:53:02 +0000 Original-Received: (at 55719) by debbugs.gnu.org; 2 Jun 2022 02:52:40 +0000 Original-Received: from localhost ([127.0.0.1]:52269 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nwawx-0003Pn-LC for submit@debbugs.gnu.org; Wed, 01 Jun 2022 22:52:39 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:63927) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nwawv-0003PW-J5 for 55719@debbugs.gnu.org; Wed, 01 Jun 2022 22:52:38 -0400 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id DCA578108D; Wed, 1 Jun 2022 22:52:31 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 48ACC8049E; Wed, 1 Jun 2022 22:52:30 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1654138350; bh=SETxIdUdt3QFDxkbNe+OD+eclPpMUQryw198QOLPObQ=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=hz45fgh7H80yLKOhWNtG5w+Scuhoa5ox2Q5p9PmAVERycrvaYLDQZlFqHRoOr96zm lJfc6ZnkmF1WuEteLU0smS5cQz6Epr9zkWv5weYZf12rYdPK5WneR6h5nY+iOgJiE5 bK+WEeOkhsxNe4e/gvn9srjIH7uO4RkCi35nm9WhEEAghiDaZ52LpGy120JGt/HaKX 9srhDnCLUBp6Z5hx3pdSk9EnXTmO7DHnWSfoZX+tw700mwAuIGA7NEqR6O3VKsADut Rdby3YDDsOW7m5Pb0RJXKDGdFo6lQFSJQx0hS/LhuY7tIE+jsqfzKI7EGHBfsJwnpg f3ovDZ5itpn/w== Original-Received: from pastel (unknown [45.72.221.51]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 195B5120475; Wed, 1 Jun 2022 22:52:30 -0400 (EDT) In-Reply-To: (Richard Hansen's message of "Wed, 1 Jun 2022 16:23:57 -0400") 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:233517 gmane.emacs.devel:290537 Archived-At: > I don't have a concrete need for it at the moment. I just noticed the bug > while I was fixing the other bugs. I can leave that change out of the patch > series if that is the only thing impeding merge. I've installed the rest of the patch series into `master`, thanks. >> The particular reason to prefer the current behavior is >> backward compatibility (which we could call "inertia"). > Anyone that needs the current behavior should be using `str N`, not > `strz N`. `str N` does not give the same semantics when unpacking. > If they're using `strz N`, then I would consider that to be a bug in > their code. It all depends how the format was defined. "NUL-terminated N-bytes-max strings" can be like the one currently supported or like the ones your code supports. Which one is better is irrelevant when the format is not of your choosing. I'm not at all opposed to supporting the kind of NUL-terminated strings you propose but it should be *in addition* to the ones already supported. > If this change breaks someone, they can fix it easily: just > change `strz N` to `str N`. No, because unpacking "a\0" with (str 2) give "a\0" rather than "a". > I understand that we should endeavor to maintain compatibility, but > keeping the current behavior would be intentionally preserving a bug > to accommodate other bugs. I don't think that's a good trade-off. It's only a bug if it doesn't match the format you need to use. Your code introduces a bug when the format is defined to behave like the current code :-( >> Note also that `strz` without a length (or with a nil length) behaves >> the way you want. > No -- strz without a length results in variable length encoding. Without > these changes, the only way to get a fixed length output with guaranteed > null termination is to do `(substring str 0 (1- N))` before packing. (Or > explicitly pack a separate zero byte immediately after the `str N-1` or > `strz N-1` entry.) ...or define a new type. >>>> (bindat-unpack spec "ab") [...] > Regardless of what other applications produce, packed strings like that are > invalid according to the spec provided to `bindat-unpack`. Where in the spec/doc of Bindat do you see that "ab" is not a valid input to `bindat-unpack` for `strz 2`? > A real example of why it might be undesirable to attempt to process > a strz string without a null terminator: You don't need to convince me that the format you propose is useful. Stefan