[RFC] Do not treat '\' as escape character on MinGW Windows hosts

[RFC] Do not treat '\' as escape character on MinGW Windows hosts

[Joel Brobecker]

[-- Attachment #1: Type: text/plain, Size: 1763 bytes --]

Hello,

With the MinGW debugger, it is currently not possible to use a path
that follows the Windows convention.  For instance:

        (gdb) file c:\foo\bar.exe
        c:foobar.exe: No such file or directory.

This is because the routine that parses arguments treats all backslashes
as an escape character.  With a MinGW tool, this does not make sense
when the argument is a path, since the canonical directory separator
on Windows is a backslash...

What the user has to do, at this point, is escape every backslash,
which can be quite painful when the path starts getting longer...

        (gdb) file c:\\foo\\bar.exe
        Reading symbols from c:\foo\bar.exe...done.

What we have done, at AdaCore, is disabling the special nature of
the backslash character when the host is MinGW (we left cygwin alone,
since cygwin users most likely expect a unix-y type of behavior).
It's a incompatible change, and as you'll see with the attached patch,
it changes the behavior for all arguments, not just path names.
Polling the few Windows users we have a AdaCore, they all seem to agree
that they did not expect backslash to be a special character in any
context, so the change seemed right to them.

Before officially submitting this patch for inclusion (including
formal testing), I wanted to see what the feeling towards this sort
of change was...

Note that GDB uses a wrapper around this routine, mostly to add
an out-of-memory exception raised when the routine returns null.
One possible way of achieving the same result, while limiting the
change to GDB alone, would be to modify the gdb_buildargv routine
to escape all backslashes before calling libiberty's buildargv.
But I think that other tools should also consider this change as
beneficial.

-- 
Joel

[-- Attachment #2: argv-mingw.diff --]
[-- Type: text/x-diff, Size: 1104 bytes --]

diff --git a/libiberty/argv.c b/libiberty/argv.c
index 3084248..b5cf71f 100644
--- a/libiberty/argv.c
+++ b/libiberty/argv.c
@@ -177,7 +177,8 @@ returned, as appropriate.
 
 */
 
-char **buildargv (const char *input)
+char **
+buildargv (const char *input)
 {
   char *arg;
   char *copybuf;
@@ -189,6 +190,15 @@ char **buildargv (const char *input)
   char **argv = NULL;
   char **nargv;
 
+/* On Windows hosts, the backslash character should not be treated
+   as an escape character.  Define a constant bs_is_escape whose value
+   is non-zero when the backslash is an escape character.  */
+#if !defined (__MINGW32__)
+  const int bs_is_escape = 1;
+#else
+  const int bs_is_escape = 0;
+#endif
+
   if (input != NULL)
     {
       copybuf = (char *) alloca (strlen (input) + 1);
@@ -234,12 +244,12 @@ char **buildargv (const char *input)
 		}
 	      else
 		{
-		  if (bsquote)
+		  if (bs_is_escape && bsquote)
 		    {
 		      bsquote = 0;
 		      *arg++ = *input;
 		    }
-		  else if (*input == '\\')
+		  else if (bs_is_escape && (*input == '\\'))
 		    {
 		      bsquote = 1;
 		    }

Re: [RFC] Do not treat '\' as escape character on MinGW Windows hosts

[Christopher Faylor]

On Wed, Apr 21, 2010 at 04:33:54PM -0400, Joel Brobecker wrote:
>Hello,
>
>With the MinGW debugger, it is currently not possible to use a path
>that follows the Windows convention.  For instance:
>
>        (gdb) file c:\foo\bar.exe
>        c:foobar.exe: No such file or directory.
>
>This is because the routine that parses arguments treats all backslashes
>as an escape character.  With a MinGW tool, this does not make sense
>when the argument is a path, since the canonical directory separator
>on Windows is a backslash...
>
>What the user has to do, at this point, is escape every backslash,
>which can be quite painful when the path starts getting longer...
>
>        (gdb) file c:\\foo\\bar.exe
>        Reading symbols from c:\foo\bar.exe...done.

Why not just use a "forward" slash?

cgf

Re: [RFC] Do not treat '\' as escape character on MinGW Windows hosts

[Joel Brobecker]

> >        (gdb) file c:\\foo\\bar.exe
> >        Reading symbols from c:\foo\bar.exe...done.
> 
> Why not just use a "forward" slash?

It's not always that easy - A lot of times, the user wants to copy/paste
a path that's been printed by another tool.  Also, the typical Windows
user seems to think that he should be able to use a valid Windows path
(which I agree)...

-- 
Joel

Re: [RFC] Do not treat '\' as escape character on MinGW Windows hosts

[Christopher Faylor]

On Wed, Apr 21, 2010 at 08:17:14PM -0400, Joel Brobecker wrote:
>> >        (gdb) file c:\\foo\\bar.exe
>> >        Reading symbols from c:\foo\bar.exe...done.
>> 
>> Why not just use a "forward" slash?
>
>It's not always that easy - A lot of times, the user wants to copy/paste
>a path that's been printed by another tool.  Also, the typical Windows
>user seems to think that he should be able to use a valid Windows path
>(which I agree)...

I agree too except when we're talking about something that is
essentially a UNIX tool.  And, I don't see how you can talk about the
pain of doubling up the backslashes if you're talking about cutting and
pasting.

I know I'll be outvoted here but I I hate cluttering code with MS-DOS
workarounds.

cgf

Re: [RFC] Do not treat '\' as escape character on MinGW Windows hosts

[Mark Kettenis]

> Date: Wed, 21 Apr 2010 22:34:21 -0400
> From: Christopher Faylor <cgf-use-the-mailinglist-please@sourceware.org>
> 
> On Wed, Apr 21, 2010 at 08:17:14PM -0400, Joel Brobecker wrote:
> >> >        (gdb) file c:\\foo\\bar.exe
> >> >        Reading symbols from c:\foo\bar.exe...done.
> >> 
> >> Why not just use a "forward" slash?
> >
> >It's not always that easy - A lot of times, the user wants to copy/paste
> >a path that's been printed by another tool.  Also, the typical Windows
> >user seems to think that he should be able to use a valid Windows path
> >(which I agree)...
> 
> I agree too except when we're talking about something that is
> essentially a UNIX tool.  And, I don't see how you can talk about the
> pain of doubling up the backslashes if you're talking about cutting and
> pasting.
> 
> I know I'll be outvoted here but I I hate cluttering code with MS-DOS
> workarounds.

You're not alone.

Re: [RFC] Do not treat '\' as escape character on MinGW Windows hosts

[Joel Brobecker]

> I agree too except when we're talking about something that is
> essentially a UNIX tool.  And, I don't see how you can talk about the
> pain of doubling up the backslashes if you're talking about cutting and
> pasting.

Perhaps I shouldn't have based some of my argumentation on convenience,
since the degree of convenience varies from user to user [1], and thus
is a weak argument at best.

What we need to decide, as a group, is whether GDB is indeed a Unix tool,
and whether GDB should treat the Windows users as Unix users stuck on
Windows (I definitely feel that way everytime I have to do Windows work).
However, my observation of the group of users that sent me some feedback
do not have that perception at all. For them GDB is just a tool, not
a Unix tool, so they do not understand why GDB does not accept valid
Windows paths.

> I know I'll be outvoted here but I I hate cluttering code with MS-DOS
> workarounds.

Understood, and it's not obvious to me that you'll be outvoted. This
is why I am asking for comments more than a review at this point.
I would like to challenge the "workaround" term, though :-P. I much as
I dislike Windows (and believe me, I really dislike this platform),
I think that if we are going to support Windows, we should support it
as a first class citizen.

-- 
Joel

[1]: Most of my Windows work is done remotely from a Linux machine,
     where copy/pasting is super easy (I have ctrl-y configured to paste
     in my xterm).

Re: [RFC] Do not treat '\' as escape character on MinGW Windows hosts

[Chris Moller]

On 04/21/10 22:34, Christopher Faylor wrote:
> On Wed, Apr 21, 2010 at 08:17:14PM -0400, Joel Brobecker wrote:
>    
>>>>         (gdb) file c:\\foo\\bar.exe
>>>>         Reading symbols from c:\foo\bar.exe...done.
>>>>          
>>> Why not just use a "forward" slash?
>>>        
>> It's not always that easy - A lot of times, the user wants to copy/paste
>> a path that's been printed by another tool.  Also, the typical Windows
>> user seems to think that he should be able to use a valid Windows path
>> (which I agree)...
>>      
>
> I agree too except when we're talking about something that is
> essentially a UNIX tool.  And, I don't see how you can talk about the
> pain of doubling up the backslashes if you're talking about cutting and
> pasting.
>
> I know I'll be outvoted here but I I hate cluttering code with MS-DOS
> workarounds.
>    

+1

> cgf
>    

Re: [RFC] Do not treat '\' as escape character on MinGW Windows hosts

[Joel Brobecker]

[-- Attachment #1: Type: text/plain, Size: 5082 bytes --]

Ooops - I had intended to start this email thread on GCC-patches,
Cc'ing GDB-patches, but I made a typo, and sent it to GDB-patches
Cc'ing the very same GDB-patches. I hope you'll forgive the cross post,
but since this is common code...

Here is what has been discussed, so far... I'm mostly trying to discuss
the idea of making backslash a normal character as opposed to an escape
character in arguments when on (MinGW) windows, whether the idea gets
sufficiently positive feedback that we can move ahead an implement this
suggestion (patch attached FYI).

Joel Brobecker:
> With the MinGW debugger, it is currently not possible to use a path
> that follows the Windows convention.  For instance:
> 
>         (gdb) file c:\foo\bar.exe
>         c:foobar.exe: No such file or directory.
> 
> This is because the routine that parses arguments treats all backslashes
> as an escape character.  With a MinGW tool, this does not make sense
> when the argument is a path, since the canonical directory separator
> on Windows is a backslash...
> 
> What the user has to do, at this point, is escape every backslash,
> which can be quite painful when the path starts getting longer...
> 
>         (gdb) file c:\\foo\\bar.exe
>         Reading symbols from c:\foo\bar.exe...done.
> 
> What we have done, at AdaCore, is disabling the special nature of
> the backslash character when the host is MinGW (we left cygwin alone,
> since cygwin users most likely expect a unix-y type of behavior).
> It's a incompatible change, and as you'll see with the attached patch,
> it changes the behavior for all arguments, not just path names.
> Polling the few Windows users we have a AdaCore, they all seem to agree
> that they did not expect backslash to be a special character in any
> context, so the change seemed right to them.
> 
> Before officially submitting this patch for inclusion (including
> formal testing), I wanted to see what the feeling towards this sort
> of change was...
> 
> Note that GDB uses a wrapper around this routine, mostly to add
> an out-of-memory exception raised when the routine returns null.
> One possible way of achieving the same result, while limiting the
> change to GDB alone, would be to modify the gdb_buildargv routine
> to escape all backslashes before calling libiberty's buildargv.
> But I think that other tools should also consider this change as
> beneficial.

Chris Faylor:
> >         (gdb) file c:\\foo\\bar.exe
> >         Reading symbols from c:\foo\bar.exe...done.
> Why not just use a "forward" slash?

Joel Brobecker:
> It's not always that easy - A lot of times, the user wants to copy/paste
> a path that's been printed by another tool.  Also, the typical Windows
> user seems to think that he should be able to use a valid Windows path
> (which I agree)...

Chris Faylor:
> >It's not always that easy - A lot of times, the user wants to copy/paste
> >a path that's been printed by another tool.  Also, the typical Windows
> >user seems to think that he should be able to use a valid Windows path
> >(which I agree)...
> 
> I agree too except when we're talking about something that is
> essentially a UNIX tool.  And, I don't see how you can talk about the
> pain of doubling up the backslashes if you're talking about cutting and
> pasting.
> 
> I know I'll be outvoted here but I I hate cluttering code with MS-DOS
> workarounds.

Mark Kettenis:
> > I know I'll be outvoted here but I I hate cluttering code with MS-DOS
> > workarounds.
> 
> You're not alone.

Joel Brobecker answered Chris:
> > I agree too except when we're talking about something that is
> > essentially a UNIX tool.  And, I don't see how you can talk about the
> > pain of doubling up the backslashes if you're talking about cutting and
> > pasting.
> 
> Perhaps I shouldn't have based some of my argumentation on convenience,
> since the degree of convenience varies from user to user [1], and thus
> is a weak argument at best.
> 
> What we need to decide, as a group, is whether GDB is indeed a Unix tool,
> and whether GDB should treat the Windows users as Unix users stuck on
> Windows (I definitely feel that way everytime I have to do Windows work).
> However, my observation of the group of users that sent me some feedback
> do not have that perception at all. For them GDB is just a tool, not
> a Unix tool, so they do not understand why GDB does not accept valid
> Windows paths.
> 
> > I know I'll be outvoted here but I I hate cluttering code with MS-DOS
> > workarounds.
> 
> Understood, and it's not obvious to me that you'll be outvoted. This
> is why I am asking for comments more than a review at this point.
> I would like to challenge the "workaround" term, though :-P. I much as
> I dislike Windows (and believe me, I really dislike this platform),
> I think that if we are going to support Windows, we should support it
> as a first class citizen.
> 
> --
> Joel
>  
> [1]: Most of my Windows work is done remotely from a Linux machine,
>      where copy/pasting is super easy (I have ctrl-y configured to paste
>      in my xterm).

-- 
Joel

[-- Attachment #2: argv-mingw.diff --]
[-- Type: text/x-diff, Size: 1104 bytes --]

diff --git a/libiberty/argv.c b/libiberty/argv.c
index 3084248..b5cf71f 100644
--- a/libiberty/argv.c
+++ b/libiberty/argv.c
@@ -177,7 +177,8 @@ returned, as appropriate.
 
 */
 
-char **buildargv (const char *input)
+char **
+buildargv (const char *input)
 {
   char *arg;
   char *copybuf;
@@ -189,6 +190,15 @@ char **buildargv (const char *input)
   char **argv = NULL;
   char **nargv;
 
+/* On Windows hosts, the backslash character should not be treated
+   as an escape character.  Define a constant bs_is_escape whose value
+   is non-zero when the backslash is an escape character.  */
+#if !defined (__MINGW32__)
+  const int bs_is_escape = 1;
+#else
+  const int bs_is_escape = 0;
+#endif
+
   if (input != NULL)
     {
       copybuf = (char *) alloca (strlen (input) + 1);
@@ -234,12 +244,12 @@ char **buildargv (const char *input)
 		}
 	      else
 		{
-		  if (bsquote)
+		  if (bs_is_escape && bsquote)
 		    {
 		      bsquote = 0;
 		      *arg++ = *input;
 		    }
-		  else if (*input == '\\')
+		  else if (bs_is_escape && (*input == '\\'))
 		    {
 		      bsquote = 1;
 		    }

Re: [RFC] Do not treat '\' as escape character on MinGW Windows hosts

[Chris Moller]

On 04/22/10 06:37, Joel Brobecker wrote:
>
>> I know I'll be outvoted here but I I hate cluttering code with MS-DOS
>> workarounds.
>>      
>
> Understood, and it's not obvious to me that you'll be outvoted. This
> is why I am asking for comments more than a review at this point.
> I would like to challenge the "workaround" term, though :-P. I much as
> I dislike Windows (and believe me, I really dislike this platform),
> I think that if we are going to support Windows,

That, then, is the fundamental question.  Certainly, Windows support 
adds to code complexity, which is always a bad thing.

>   we should support it
> as a first class citizen.
>
>    

RE: [RFC] Do not treat '\' as escape character on MinGW Windows hosts

[Pierre Muller]

> -----Message d'origine-----
> De : gdb-patches-owner@sourceware.org [mailto:gdb-patches-
> owner@sourceware.org] De la part de Joel Brobecker
> Envoyé : Thursday, April 22, 2010 1:52 PM
> À : gcc-patches@gcc.gnu.org
> Cc : gdb-patches@sourceware.org
> Objet : Re: [RFC] Do not treat '\' as escape character on MinGW Windows
> hosts
> 
> Ooops - I had intended to start this email thread on GCC-patches,
> Cc'ing GDB-patches, but I made a typo, and sent it to GDB-patches
> Cc'ing the very same GDB-patches. I hope you'll forgive the cross post,
> but since this is common code...
> 
> Here is what has been discussed, so far... I'm mostly trying to discuss
> the idea of making backslash a normal character as opposed to an escape
> character in arguments when on (MinGW) windows, whether the idea gets
> sufficiently positive feedback that we can move ahead an implement this
> suggestion (patch attached FYI).

  Should we rather think about a command
that would allow to switch from Unix to Windows behavior?

set windows-escape-mode on/auto/off

The default 'auto' mode
would adapt to the target we are debugging
which would be 'on' for mingw* targets and possibly other Windows-like
targets
and 'off' for most others (this would become a gdbarch or a tdep field...).

  People that really dislike this could still
force old behavior by setting
'set windows-escape-mode' to 'off'.

Of course this is only valid for GDB, I don't know
how this could be handled within GCC.


Pierre Muller
Pascal language support maintainer for GDB

Re: [RFC] Do not treat '\' as escape character on MinGW Windows hosts

[Joel Brobecker]

>   Should we rather think about a command
> that would allow to switch from Unix to Windows behavior?
> 
> set windows-escape-mode on/auto/off

Absolutely, *if* we decide that the right behavior is: preserve the
current Unixy behavior everywhere except inside the GDB interpreter.

> Of course this is only valid for GDB, I don't know
> how this could be handled within GCC.

GCC already accepts both forms, I suspect.  However, the shell from
which you are calling GCC might not. For instance, if you use a cygwin
bash to call GCC, then you cannot use c:\foo.c unless you either escape
the backslashes, or you quote your argument. But if you do it from the
CMD.exe shell, then it should work just fine.

-- 
Joel

Re: [RFC] Do not treat '\' as escape character on MinGW Windows hosts

[Joel Brobecker]

> >Understood, and it's not obvious to me that you'll be outvoted. This
> >is why I am asking for comments more than a review at this point.
> >I would like to challenge the "workaround" term, though :-P. I much as
> >I dislike Windows (and believe me, I really dislike this platform),
> >I think that if we are going to support Windows,
> 
> That, then, is the fundamental question.  Certainly, Windows support
> adds to code complexity, which is always a bad thing.

Let's imagine that we have a bug in the software, can we reasonably tell
the user that his bug will not be fixed because the fix complexifies
the code?  To a Windows user, not being able to use backslashes in paths
is a bug!

-- 
Joel

Re: [RFC] Do not treat '\' as escape character on MinGW Windows hosts

[André Pönitz]

On Thursday 22 April 2010 04:34:21 Christopher Faylor wrote:
> On Wed, Apr 21, 2010 at 08:17:14PM -0400, Joel Brobecker wrote:
> >> >        (gdb) file c:\\foo\\bar.exe
> >> >        Reading symbols from c:\foo\bar.exe...done.
> >> 
> >> Why not just use a "forward" slash?
> >
> >It's not always that easy - A lot of times, the user wants to copy/paste
> >a path that's been printed by another tool.  Also, the typical Windows
> >user seems to think that he should be able to use a valid Windows path
> >(which I agree)...
> 
> I agree too except when we're talking about something that is
> essentially a UNIX tool

Isn't gdb aiming at supporting (at least?) the same environments as 
gcc does?

If so, the answer seems pretty clear to me: gcc works for MinGW,
so gdb should "just work", too. Whether this boils down to making
a backslash an ordinary character, or have some setting for it
is another question. 

I do understand that gdb has a UNIX history, but telling people "If you
mean 'a', type 'b'" strikes me as odd - no matter what the context is.

> And, I don't see how you can talk about the pain of doubling up 
> the backslashes if you're talking about cutting and pasting.

If you cut&paste paths from a shell or browser on Windows you'll get 
single backslashs. Some applications (also lots with a UNIX history)
can handle that, some not. In the latter cases the user has to manually
"fix" (he might even call it "cripple") the pasted path to make that 
application happy.  That's slow, prone to error, and ugly.

gdb has by now a _huge_ potential to be _the_ cross-platform debugging
solution. In practice, it is hampered by usability issues like that to a 
degree that makes it practically unusable in a lot of scenarios - also 
on UNIX btw.

> I know I'll be outvoted here but I I hate cluttering code with MS-DOS
> workarounds.

Oh well... For me the "joy" of application development has always been to
take some burden from the user and place it on the sholders of the developer.
And in a cross-platform environment this sometimes may mean using the 
preprocessor, or use an otherwise unneeded abstraction layer.

Sure, this makes the application code more complex, but isn't making 
applications doing something useful the actual goal of making them?

Andre'

Re: [RFC] Do not treat '\' as escape character on MinGW Windows hosts

[Joel Brobecker]

I didn't get much feedback on this. I thought it would have stirred
a little more controversy ;-). Since the feedback that we did get
went both ways, we'll just keep that an AdaCore-specific feature.

On Wed, Apr 21, 2010 at 04:33:54PM -0400, Joel Brobecker wrote:
> Hello,
> 
> With the MinGW debugger, it is currently not possible to use a path
> that follows the Windows convention.  For instance:
> 
>         (gdb) file c:\foo\bar.exe
>         c:foobar.exe: No such file or directory.
> 
> This is because the routine that parses arguments treats all backslashes
> as an escape character.  With a MinGW tool, this does not make sense
> when the argument is a path, since the canonical directory separator
> on Windows is a backslash...
> 
> What the user has to do, at this point, is escape every backslash,
> which can be quite painful when the path starts getting longer...
> 
>         (gdb) file c:\\foo\\bar.exe
>         Reading symbols from c:\foo\bar.exe...done.
> 
> What we have done, at AdaCore, is disabling the special nature of
> the backslash character when the host is MinGW (we left cygwin alone,
> since cygwin users most likely expect a unix-y type of behavior).
> It's a incompatible change, and as you'll see with the attached patch,
> it changes the behavior for all arguments, not just path names.
> Polling the few Windows users we have a AdaCore, they all seem to agree
> that they did not expect backslash to be a special character in any
> context, so the change seemed right to them.
> 
> Before officially submitting this patch for inclusion (including
> formal testing), I wanted to see what the feeling towards this sort
> of change was...
> 
> Note that GDB uses a wrapper around this routine, mostly to add
> an out-of-memory exception raised when the routine returns null.
> One possible way of achieving the same result, while limiting the
> change to GDB alone, would be to modify the gdb_buildargv routine
> to escape all backslashes before calling libiberty's buildargv.
> But I think that other tools should also consider this change as
> beneficial.
> 
> -- 
> Joel

> diff --git a/libiberty/argv.c b/libiberty/argv.c
> index 3084248..b5cf71f 100644
> --- a/libiberty/argv.c
> +++ b/libiberty/argv.c
> @@ -177,7 +177,8 @@ returned, as appropriate.
>  
>  */
>  
> -char **buildargv (const char *input)
> +char **
> +buildargv (const char *input)
>  {
>    char *arg;
>    char *copybuf;
> @@ -189,6 +190,15 @@ char **buildargv (const char *input)
>    char **argv = NULL;
>    char **nargv;
>  
> +/* On Windows hosts, the backslash character should not be treated
> +   as an escape character.  Define a constant bs_is_escape whose value
> +   is non-zero when the backslash is an escape character.  */
> +#if !defined (__MINGW32__)
> +  const int bs_is_escape = 1;
> +#else
> +  const int bs_is_escape = 0;
> +#endif
> +
>    if (input != NULL)
>      {
>        copybuf = (char *) alloca (strlen (input) + 1);
> @@ -234,12 +244,12 @@ char **buildargv (const char *input)
>  		}
>  	      else
>  		{
> -		  if (bsquote)
> +		  if (bs_is_escape && bsquote)
>  		    {
>  		      bsquote = 0;
>  		      *arg++ = *input;
>  		    }
> -		  else if (*input == '\\')
> +		  else if (bs_is_escape && (*input == '\\'))
>  		    {
>  		      bsquote = 1;
>  		    }


-- 
Joel

Re: [RFC] Do not treat '\' as escape character on MinGW Windows hosts

[Sergio Durigan Junior]

On Wednesday 05 May 2010 15:48:59, Joel Brobecker wrote:
> I didn't get much feedback on this. I thought it would have stirred
> a little more controversy ;-). Since the feedback that we did get
> went both ways, we'll just keep that an AdaCore-specific feature.

I know it may be too late for that and I don't want to bring old discussions 
back to live, but FWIW I agree with you and André, in the way that GDB should 
correctly handle the backslash on MinGW environments.

I don't use Windows and I share your feelings about its quality, but I have 
this feeling that, if we're going to support something, we should really 
support it.  Too bad this patch (apparently) won't go in.

-- 
Sergio

Re: [RFC] Do not treat '\' as escape character on MinGW Windows hosts

[Tom Tromey]

>>>>> "Sergio" == Sergio Durigan Junior <sergiodj@redhat.com> writes:

Joel> I didn't get much feedback on this. I thought it would have stirred
Joel> a little more controversy ;-). Since the feedback that we did get
Joel> went both ways, we'll just keep that an AdaCore-specific feature.

Sergio> I know it may be too late for that and I don't want to bring old
Sergio> discussions back to live, but FWIW I agree with you and André,
Sergio> in the way that GDB should correctly handle the backslash on
Sergio> MinGW environments.

Thanks for speaking up.
This seems reasonable to me too.

I am not as certain about the particular implementation, though it is
hard to see how else it could work.

Tom