On 07/05/2011 10:58 AM, Bruce Korb wrote: > On 07/05/11 08:06, Eric Blake wrote: >> I'm not quite sure what you are asking me to do here. Maybe it helps to >> read the current POSIX requirements on uuencode output: >> >> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/uuencode.html > > I read that, though I was sure not as carefully as someone regularly in > on the meeting. :) Reading it again: > >> The pathname of the file into which the uudecode utility shall place >> the decoded file. ... If there are >> characters in decode_pathname that are not in the portable filename >> character set the results are unspecified. > ==>> ^^^^ needs a comma after "set". > > leads me to believe that this: > > begin 444 hex-encode-EN:414243 > > can, for example, be validly used to create a file named "ABC" > in the english language domain, with obvious extensions for CN. > The ":" character being non-portable relieves the application from > being required to create a file named "hex-encode-EN:414243".
You are correct that it would work. The ':' cannot appear in any file created by a POSIX-compliant use of uuencode, therefore uudecode, upon seeing a ':' in the file name position, can assume that the input file must have been created by a uuencode version that was using an extension to POSIX, and therefore uudecode can blindly try to decode that name without violating POSIX. > It is just that a new uudecode might surprise someone trying > to create a file named "hex-encode-DE:BADF". Under your encoding scheme for all possible filenames that fall outside the bounds of the POSIX portable file name set, you merely encode such a file name as: begin 444 hex-encode-EN:6865782d656e636f64652d44453a42414446 that is, presence of : in the desired output name implies that the file name must be encoded, just the same as any 8-bit byte also makes that implication. -- Eric Blake ebl...@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
