Re: CVS commit: src/external/bsd/libarchive/dist/libarchive

> While the unix-ish interpretation that mouse potinted at is great
> when using the archive in the same context it was created, it forces
> other extractors to guess the encoding, which is pretty bad.

Unix pathnames have historically been octet strings, uninterpreted
except for slash and NUL.  I would certainly *hope* that they still are
at the syscall level; anything else is IMO a "renders it unusable" bug.
Treating filenames as character strings anywhere but user presentation
leads directly to a large morass of trouble.

"[O]ther extractors" shouldn't be doing anything with encodings; they
should be taking the octet string given and using it as the pathname to
the relevant syscall(s).  (Unless specifically told to remap, but I'm
not sure I'd consider even that much sane.)

If there are extractors running on systems where filenames are
character strings instead of octet strings, they will need impedance
matching, but that's always been true.

> I am one of the few remaining users (I guess) of non-ASCII and
> non-UTF8 locales.

I don't know about "few", but I'm another.  I use 8859-1 routinely,
8859-14 a bit less routinely but still relatively commonly.  In a few
cases I even have both in the same directory, I think.  Maybe a few
others; not sure.  My reaction to variable-size characters is very much
"delenda est".

I'm not going to stop doing so, either.  Anything that can't handle the
resulting octet strings will, on my systems, get fixed, replaced, or at
worst used only for use cases where its brokenness is tolerable.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		[email protected]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B