Tcl Source Code

According to http://en.wikipedia.org/wiki/Uuencode we do uuencoding wrong. In particular (ignoring the header and footer) uuencoding always uses a line length of 61 (encoding 45 bytes as 60 bytes with a length character preceding, typically an 'M' for 45 bytes). Wrap char is always \n (of course). The data is finished off with a line containing zero characters. And a backtick/grave accent (`) is often substituted for space so things don't get mangled.

I'd be perfectly happy at leaving the header/footer processing off. ;-)

Committed to trunk. Thanks for your help, Jan.

Thanks! Implementation looks OK to me.

OK, I can live with it. I've tweaked it to work with bytearrays, as everything else is done that way.

I know that -wrapchar is of veeeeeeery limited use, but removing an existing options is not something I would expect in a bug-fix release. That's my main reason for adding it. But I would support removing it in Tcl 9 (or even Tcl 8.7).

It's not that we couldn't do a -wrapchar, but if we did, we might as well allow specifying of the profile of encoding characters to use as well; it's that useless.

If it was purely up to me, someone really needing the functionality could use string map afterwards. (You're holding the data in memory anyway…)

That's really useless you know? Absolutely no conforming code can use it, and its implementation meant that even the use case you mentioned wouldn't have worked (the old code assumed that it was dealing with a single byte, probably a single non-NUL ASCII byte at that). If there's an option that you cannot touch without making the operation useless, it's best omitted. (Pat assumed that uuencoding was just the same as base64, except with a different encoding alphabet, but that's just not true. I remember because I used to use uuencoding a lot in the early '90s for archive files, and wikipedia backs me up.)

There's now a correct decoder done too; it can consume correct data files with only the need for header and footer processing added.

There might be cause to have some sort of enforcement of strictness, but that's of pretty low value IMO (being able to use a streaming version would be much more relevant, and also clearly in the realm of New Feature).

Added back the -wrapchar option. I don't think it's really useful, but we cannot be sure no-one used it (e.g. it could be set to "\r\n").

I've got a fix for the encoding side on this branch: bug-2152292. It still needs some work so that it also correctly decodes.

Bumping prio; without the length byte (and hence line handling) the encoding/unencoding is actually incorrect. Alas.

Length byte processing is important, and that means that splitting into lines is important.