GNU bug report logs - #10474
Building guile 2.x under mingw + msys

Previous Next

Full log

Message #89 received at 10474 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andy Wingo <wingo <at> pobox.com>
Cc: ludo <at> gnu.org, 10474 <at> debbugs.gnu.org
Subject: Re: bug#10474: Building guile 2.x under mingw + msys
Date: Tue, 19 Feb 2013 19:53:57 +0200

> From: Andy Wingo <wingo <at> pobox.com>
> Cc: ludo <at> gnu.org,  10474 <at> debbugs.gnu.org
> Date: Tue, 19 Feb 2013 11:44:35 +0100
> 
> >  . module/ice-9/boot-9.scm -- absolute-path? does not support Windows
> >                               file names with drive letters.  Windows
> >                               absolute file names match the regex
> >                               "\([a-zA-Z]:\)?[\\/]".  I don't know
> >                               Scheme well enough to write this in a
> >                               clean way, sorry...
> 
> Ludo, what do you think about the attached patch?  Eli, is it correct
> and sufficient to fix path handling?

Yes, I think so.  I have a couple of comments, though:

> +       (define (unc-path?)
> +         ;; Universal Naming Convention (UNC) paths start with \\, and
> +         ;; are always absolute.
> +         (string-prefix? "\\\\" path))

A UNC file name can also begin with 2 slashes, as in "//foo/bar/".  In
general, Windows system calls treat both kinds of slashes identically.

>    (define (canonical->suffix canon)
>      (cond
> -     ((string-prefix? "/" canon) canon)
> -     ((and (> (string-length canon) 2)
> -           (eqv? (string-ref canon 1) #\:))
> -      ;; Paths like C:... transform to /C...
> -      (string-append "/" (substring canon 0 1) (substring canon 2)))
> +     ((and (not (string-null? canon))
> +           (path-separator? (string-ref canon 0)))
> +      canon)
> +     ((and (eq? (system-path-convention) 'windows)
> +           (absolute-path? canon))
> +      ;; An absolute path that doesn't start with a path separator starts with a
> +      ;; drive component.  Transform the drive component to a path element:
> +      ;; c:\foo -> \c\foo.

Why is this transformation needed?  Native Windows system calls will
not understand "/c/foo" syntax.  What is this about?  (I know it was
in the original code, but I didn't understand it then, either.)

Previous Next

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