bug#56469: 29.0.50; Unibyte dir in directory_files_internal

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: 56469@debbugs.gnu.org
> Date: Sun, 10 Jul 2022 10:58:30 -0400
> 
> Eli Zaretskii [2022-07-10 17:32:17] wrote:
> 
> > I don't think this is true, because early during startup we don't yet
> > have the coding-systems set up, and so the file names are unibyte and
> > undecoded.  So that place in dired.c doesn't only handle ASCII when it
> > sees that ncahrs == nbytes.
> 
> Hmm... the early startup is actually not a worry here (according to my
> tests `directory_files_internal` is first called when we get to
> native-compile the macroexp/bytecomp, at which point all our coding
> systems have been setup).

That could be the situation _today_, but that's just sheer luck (or
lack thereof).  In general, all the file-handling code we have in
fileio.c and dired.c should be equally prepared to handle unibyte
non-ASCII file names and multibyte file names, because we may need
that any time.  When we make changes in Emacs, we shouldn't be worried
whether those changes could cause some dired.c code be called early on
during Emacs startup.