GNU bug report logs - #55815
[PATCH] bindat: Improve str, strz documentation

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Richard Hansen <rhansen <at> rhansen.org>
Cc: 55815 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: bug#55815: [PATCH] bindat: Improve str, strz documentation
Date: Tue, 07 Jun 2022 19:30:25 +0300

> Date: Mon, 6 Jun 2022 19:31:35 -0400
> Cc: 55815 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
> From: Richard Hansen <rhansen <at> rhansen.org>
> 
> > 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?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.