bug#18310: 24.3.93; relative links don't work in eww and Windows 7

[Eli Zaretskii]

> From: joaotavora@gmail.com (João Távora)
> Cc: 18310@debbugs.gnu.org
> Date: Thu, 21 Aug 2014 17:54:11 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: joaotavora@gmail.com (João Távora)
> >> Cc: 18310@debbugs.gnu.org
> >> Date: Thu, 21 Aug 2014 16:43:48 +0100
> >> 
> >> Something other than `default-directory' seems to be influencing it. I
> >> did some tests:
> >
> > Like I said: Emacs uses the current drive to complete the missing
> > drive letter.  That is what you see.
> 
> OK. How is the "current drive" calculated when `default-directory' is
> nil?

There's a system call to get the "current drive", where Emacs runs.

> >> Finally
> >> 
> >>    (let ((default-directory "\\\\"))
> >>      (expand-file-name "../" "/something/bla"))
> >> 
> >> Crashed the Emacs process on my machine.
> >
> > It's not a crash, it's a deliberate abort.  "\\\\" (i.e., 2
> > backslashes in a row without anything after that) is an invalid file
> > name on Windows.
> 
> Would signalling an error be very wrong, does the process really need to
> be aborted?

Yes.  This is a deliberate trap for code either in Emacs itself or in
Lisp applications that uses such invalid default-directory values.

> I mean unprotected code may easily lead to that invalid case.

Not "easily", no.  Usually, default-directory comes from some file or
buffer.  But if some code does use that, we want to catch it
red-handed, because there's no way to know what other damage it can do
down the road.

> BTW "Semi-invalid" uses, or even downright absurd use cases, are what
> development/testing/experimentation is all about. IMO aborting the
> process and not at least warning elisp users about invalid cases in the
> documentation is not good practice in my opinion.

Emacs is not mission-critical software.  If it were, then I'd agree
with you (I happen to develop mission-critical software for a living).