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#55815: [PATCH] bindat: Improve str, strz documentation Date: Tue, 07 Jun 2022 19:30:25 +0300 Message-ID: <831qw077xa.fsf@gnu.org> References: <3fc223d1-6dc0-6f59-1b27-d72dd8a3004e@rhansen.org> <83h74y83bz.fsf@gnu.org> <13fe3d31-c2a7-f2ea-ba1a-305d5f5924ed@rhansen.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16028"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 55815@debbugs.gnu.org, monnier@iro.umontreal.ca To: Richard Hansen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Jun 07 18:31:15 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 1nyc6s-0003uL-7P for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 07 Jun 2022 18:31:14 +0200 Original-Received: from localhost ([::1]:41968 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nyc6r-0002Ev-B2 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 07 Jun 2022 12:31:13 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58220) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nyc6g-00025I-Kx for bug-gnu-emacs@gnu.org; Tue, 07 Jun 2022 12:31:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:47364) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nyc6g-0000c3-BP for bug-gnu-emacs@gnu.org; Tue, 07 Jun 2022 12:31:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nyc6g-0006Xg-2x for bug-gnu-emacs@gnu.org; Tue, 07 Jun 2022 12:31: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: Tue, 07 Jun 2022 16:31:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 55815 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 55815-submit@debbugs.gnu.org id=B55815.165461945125132 (code B ref 55815); Tue, 07 Jun 2022 16:31:02 +0000 Original-Received: (at 55815) by debbugs.gnu.org; 7 Jun 2022 16:30:51 +0000 Original-Received: from localhost ([127.0.0.1]:41261 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nyc6V-0006XI-CT for submit@debbugs.gnu.org; Tue, 07 Jun 2022 12:30:51 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:44952) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nyc6T-0006X1-FL for 55815@debbugs.gnu.org; Tue, 07 Jun 2022 12:30:49 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:40482) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nyc6L-0000UN-9N; Tue, 07 Jun 2022 12:30:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=QjS7nlQoZmHazAzKUbR8q8OvPwz9g4m6It8pIxUh2U0=; b=XgncNs4+ZIWZ 38AwGyEsCmSnaWS7YXhnWbMbfouyMWZOB00Uv7LnyabZ6TAfeTbmrCMnBmhv8xaurXoMyOC6mqjS1 2v8X5yQOdSLY8Ud5Fzz3X0vnbJjHegVOXPNXQNH3+RS+HyeID0auTPIpw2hlMg3jii+BAq/bU7Vvj FfQK5LU+vLnIVFv7q2GlynSV90dltWicAFXuwnV98uMUvNgBguUn0NBe19VnrP8Xlhb3lYu1Q+OJh 8sCEnUOIntcXZWA4ASXt35LlvExh7D484IrSvikXqebEp6ILdqe5FXW49AqW5AtEH2Iy9R0i8h3ig tns2BKlXukPPIDXFZ9uC8Q==; Original-Received: from [87.69.77.57] (port=3975 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nyc6H-0002y0-1X; Tue, 07 Jun 2022 12:30:41 -0400 In-Reply-To: <13fe3d31-c2a7-f2ea-ba1a-305d5f5924ed@rhansen.org> (message from Richard Hansen on Mon, 6 Jun 2022 19:31:35 -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:233910 Archived-At: > Date: Mon, 6 Jun 2022 19:31:35 -0400 > Cc: 55815@debbugs.gnu.org, monnier@iro.umontreal.ca > From: Richard Hansen > > > I think it is better to say > > > > Unibyte string that is @var{len} bytes long. > > Done. I may have gone overboard though -- I did so because there are three representations that matter: > > 1. The input string to be packed. > 2. The packed output. > 3. The result of unpacking. > > Right now all three of those are unibyte, but in a future patch I plan on changing the first to accept unibyte-convertible multibyte input strings. Not sure I understand: what do you mean by "unibyte-convertible multibyte input strings", and how do they differ from the other kinds? In any case, you say "unibyte input string" too many time, and that's unnecessary. One example: > +Unibyte string of length @var{len}. When packing, the first @var{len} > +bytes of the input string are copied to the packed output. If the > +input string is shorter than @var{len}, the remaining bytes will be > +null (zero) unless a pre-allocated string was provided to > +@code{bindat-pack}, in which case the remaining bytes are left > +unmodified. The input string must be unibyte (@pxref{Text Why do we need to say the input must be unibyte when we already said that up front? (There's more of this redundancy in the patch.) Stefan, any further comments?