GNU bug report logs - #76982
30.1; url-generic-parse-url cannot parse Windows file paths

Previous Next

Package: emacs;

Reported by: Morgan Willcock <morgan <at> ice9.digital>

Date: Wed, 12 Mar 2025 17:54:02 UTC

Severity: normal

Tags: patch

Found in version 30.1

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Sebastián Monía <sebastian <at> sebasmonia.com>
Cc: 76982 <at> debbugs.gnu.org, morgan <at> ice9.digital
Subject: bug#76982: 30.1; url-generic-parse-url cannot parse Windows file paths
Date: Mon, 07 Apr 2025 14:50:36 +0300
> From: Sebastián Monía <sebastian <at> sebasmonia.com>
> Cc: 76982 <at> debbugs.gnu.org,  morgan <at> ice9.digital
> Date: Mon, 07 Apr 2025 00:18:57 -0400
> 
> 
> Eli Zaretskii <eliz <at> gnu.org> 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.




This bug report was last modified 37 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.