A number of testsuites for packages which have
accelerators are written to load and test all available
accelerators.
The uuencode testsuite is not written to that form yet,
but should, as we have pure Tcl, critcl, and Trf
accelerators.
It is written to select one of the available
accelerators and test that. It however gets confused if
there are both critcl and Trf present. It loads and
uses critcl, but some test uuencode-1.4 reacts to the
presence of Trf and changes to expect different
results. This mismatch causes it to fail.
The results are in disagreement about the padding
character. Trf uses tilde (~), and pure Tcl/critcl use
the backtick (`). Why the difference ? Do we have a
document providing an authoritative answer to this ?
Logged In: YES
user_id=202636
The non-Trf versions use ` as this is the 0 byte
representation and this follows other uuencode
implementations (notably perl's pack('u', ' ');) The tilde
character is invalid which makes it helpful in recognising
excess bytes but may cause interoperability problems for
other decoders. In standard usage each line is prefixed by a
byte the gives the length in bytes of the relevant data so
the choice of padding should not be too important.
Interestingly I looked for a standard and found IEEE Std
1003.1-2001 gives a specification for uuencode which
specifies = as the padding character! Solaris'
implementation is using a space.
Logged In: YES
user_id=75003
In other words, this area is even more of a mess than I thought.
:(
Ok, I will consider this a low-prio thing then.
Get to unconfuse the testsuite first/only.
Hm. Might make sense to choose a padding character we can
easily detect later and then convert into whatever is needed
for compatibility when the result is used in specific tools,
like uuencode.
Logged In: YES
user_id=75003
Ok, I committed a change which deconfuses the testsuite's
belief about which accelerator is loaded and active. Keeping
this open for dealing with the padding mess, retitled entry
for that.