Re: [PATCH 2/2] mingw: allow absolute paths without drive prefix

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Hannes,

On Mon, 10 Dec 2018, Johannes Sixt wrote:

> > diff --git a/compat/mingw.c b/compat/mingw.c
> > index 34b3880b29..4d009901d8 100644
> > --- a/compat/mingw.c
> > +++ b/compat/mingw.c
> > @@ -928,11 +928,19 @@ unsigned int sleep (unsigned int seconds)
> >   char *mingw_mktemp(char *template)
> >   {
> >   	wchar_t wtemplate[MAX_PATH];
> > +	int offset = 0;
> > +
> >    if (xutftowcs_path(wtemplate, template) < 0)
> >   		return NULL;
> > +
> > +	if (is_dir_sep(template[0]) && !is_dir_sep(template[1]) &&
> > +	    iswalpha(wtemplate[0]) && wtemplate[1] == L':') {
> > +		/* We have an absolute path missing the drive prefix */
> 
> This comment is true for the source part, template, but I can't find
> where the destination, wtemplate, suddenly gets the drive prefix. As far
> as I can see, xutftowcs_path() just does a plain textual conversion
> without any interpretation of the text as path. Can you explain it?

It is legal on Windows for such a path to lack the drive prefix, also in
the wide-character version. So the explanation is: even `wtemplate` won't
get the drive prefix. It does not need to.

> BTW, iswalpha() is not restricted to ASCII letters, I would rewrite it
> as (wtemplate[0] <= 127 && isalpha(wtemplate[0]).

Very good point! Will fix.

Thanks,
Dscho



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux