bug#29189: 25.3; Dired does not work with binary filenames

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: handa@gnu.org,  vianchielfaura@gmail.com,  29189-don@debbugs.gnu.org,  
> schwab@suse.de
> Date: Sat, 06 Jan 2018 10:20:38 -0500
> 
> > Situations where file names are not valid byte sequences for the
> > locale's codeset are rare.
> 
> Hmm... then I think I have misunderstood something: why doesn't this
> problem show up with a valid name like "λ" ?

Because "λ" will be inserted by 'ls' as a valid UTF-8 sequence of raw
bytes, and will be correctly decoded.  By contrast, \265 is not a
valid UTF-8 sequence, so we need it to produce a string of a single
raw byte.

> >> I'd also be tempted to additionally signal an error if a non-byte
> >> (i.e. a char that's neither ASCII nor eight-bit-byte) is found since
> >> "decoding" in that case is meaningless.
> > I don't think I understand.  A given byte sequence can either
> > represent a decodable character or be a raw byte.  What third
> > possibility did you have in mind?
> 
> If the input is from a multibyte text, the input is not a byte sequence
> but a character sequence, so the third possibility is to have a non-byte
> in those characters.

Input that is from multibyte text can include raw bytes in their
multibyte representation.  What is a "non-byte"?