Date: Sun, 27 Mar 2022 10:35:21 +0000 From: "Piotr P. Stefaniak" <pstef@freebsd.org> To: freebsd-arch@freebsd.org Subject: Re: Introducing base64(1) Message-ID: <YkA96Zpd/1uUZJRX@freefall.freebsd.org> In-Reply-To: <YZvsnRwtPHmyinKM@freefall.freebsd.org> References: <YZvsnRwtPHmyinKM@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YkA96Zpd/1uUZJRX>