Re: Introducing base64(1)

"Piotr P. Stefaniak" <[email protected]>
Newsgroups gmane.os.freebsd.architechture
Message-ID <YkA96Zpd/[email protected]>
On 2021-11-22 19:16:45, Piotr P. Stefaniak wrote:
>Hello archers,
>
>I've prepared a short series of changes:
>https://reviews.freebsd.org/D32943 "Conflate uudecode and uuencode"
>https://reviews.freebsd.org/D32944 "b64encode: implement -w to wrap lines"
>https://reviews.freebsd.org/D32945 "Implement base64(1)"

I would like to start applying these, one by one and see what kind of
issues people will find. Hopefully nothing major.

>First, I modularize uuencode and uudecode by wrapping them in
>bin2text2bin.c ("binary to text to binary"). The program will be
>installed as bin2text2bin, uuencode, uudecode, b64encode, and b64decode
>and will be responsible for running the coders according to their
>historical behavior.
>
>Additionally, bin2text2bin will be able to take a parameter designating
>the coder and accept all its options in this form:
>bin2text2bin <coder> [options]
>and the behavior should be the same as if
><coder> [options]
>was invoked.
>This has the advantage that adding coders won't require installing them
>as binaries. I think quoted-printable or yEnc would be nice, but
>currently I have no plans to implement those.

This one is the one that I'm most concerned about since the change is
pretty invasive structure-wise. It's probably missing some cleanup like
make delete-old, but I know nothing about it.

>Second, I implement an option to b64encode that sets the column after
>which lines wrap. Plus, I accidentally optimize the function that
>produces the encoded output.

>Third, I use the existing b64encode and b64decode implementation and the
>newly implemented option to call it as base64, respecting the syntax of
>that program's invocation.

I updated the two changes mentioned above yesterday. Now getopt_long()
is used only once and then the options are passed to new special-purpose
functions. This seems cleaner than using getopt_long() to reconstruct
options for another getopt_long() loop.

I've done some git-rebasing on the way so that's another thing that
might be wrong - but I find that less likely than bugs of other sort.

Piotr
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.