Subject: Re: bug#76982: 30.1; url-generic-parse-url cannot parse Windows file paths

From: Eli Zaretskii <[email-masked]>
Date: Mon, 07 Apr 2025 14:50:36 +0300

> From: Sebastián Monía <[email-masked]>
> Cc: [email-masked],  [email-masked]
> Date: Mon, 07 Apr 2025 00:18:57 -0400
> 
> 
> Eli Zaretskii <[email-masked]> writes:
> > Ping!  Sebastián, would you like to submit an updated patch which
> > addresses my comments?
> >
> >> > @@ -210,6 +215,13 @@ url-generic-parse-url
> >> >  
> >> >            (if (and host (string-match "%[0-9][0-9]" host))
> >> >                (setq host (url-unhex-string host)))
> >> > +
> >> > +          ;; For file:// URIs, if the path "looks like" Windows/DOS, it
> >> > +          ;; makes sense to strip the leading slash (bug#76982)
> >> > +          (when (and (string= "file" scheme)
> >> > +                     (string-match "^/[A-Za-z]:[/\\]" file))
> >> > +            (setq file (substring file 1)))
> >> > +
> >> >            (url-parse-make-urlobj scheme user pass host port file
> >> >  				 fragment nil full))))))
> >> 
> >> Isn't it cleaner to go one more character forward here:
> >> 
> >>           ;; 3.2. Authority
> >>           (when (looking-at "//")
> >>             (setq full t)
> >>             (forward-char 2)  <<<<<<<<<<<<<<<<<<<<
> >>             (setq save-pos (point))
> >>             (skip-chars-forward "^/?#")
> >> 
> >> if the conditions for Windows-style absolute file name are fulfilled?
> 
> The URI could potentially have components before we get to the filename,
> so the look head for "path starts with" isn't as clean.

It can have other components in file:// URIs?  If so, can you show an
example?

> In this patch I still do that check in the same place as in the
> original.

The problem with your proposal is that the value of 'file' is
incorrect between where it is first set and where you correct it.  Any
code added later that uses 'file' in-between might cause bugs if the
person who adds such code is not aware of this subtlety.  By contrast,
under my suggestion 'file' has the correct value from the get-go.

Thanks.