bug#70914: 29.3; Crashes often on Windows

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: simendsjo@gmail.com, ssbssa@yahoo.de, corwin@bru.st, 70914@debbugs.gnu.org
> Date: Thu, 23 May 2024 13:52:21 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > My point is that if the URI is "file://", the corresponding :path on
> > Windows is not "//".
> 
> Sure. But what is passed to :activate-func is not a file path. It is
> "Org mode link path". They are not the same in this specific case, but
> there is nothing wrong on Org side.

Then on whose side is something wrong in this case?  Which code calls
file-exists-p with the string "//" in the case you described?

> >> IMHO, the bug is in file-exists-p:
> >
> > I don't think so.  "//" is an invalid file name on Windows, so the
> > only requirement from file-exists-p in that case is not to crash.
> > Which it does, after the recent fix.
> 
> IMHO, "invalid file name on Windows" leads to "trouble determining
> whether the file exists".

Since the file name "//" is invalid, you get undefined behavior.
Examples:

  (file-exists-p "//)
    => nil

but

  (file-attributes "//")
    => (t 1 1001 513 (0 0 0 0) (0 0 0 0) (0 0 0 0) 0 "drwxrwxrwx" t 0 0)

and

  (file-directory-p "//")
    => nil

> AFAIU, this is what happens after the fix anyway, so there is nothing
> more that should be done on Emacs side.

Generating such invalid file names is wrong, so it should be prevented
if possible.  But I won't argue more if you are still unconvinced.