Re: '\r' only end-of-line

[Daniel Jacobowitz <drow at false dot org>]

On Wed, Oct 11, 2006 at 12:08:07PM +0200, Denis PILAT wrote:
> >I think part of your patch is not needed: the Windows port of GDB
> >should use the LSEEK_NOT_LINEAR branch of the code in
> >find_source_lines, so the code you are patching doesn't need to
> >consider the \r\n case.
> >
> Yes but when you use a linux hosted compiler for reading windows source 
> file
> (sorry for that weirdness but we sometime have common source file for 
> both OS),
> then this case may happen.

I was just thinking about this the other day...

As a general position, are we willing to support things written /
compiled on other hosts?  This includes both line endings and
pathnames.  I hope the answer is yes, but I don't know.

At CodeSourcery, as we've said before, we ship a native Windows GDB
and GCC.  But for a lot of things we have no way to test the native
Windows GDB - can't use Cygwin's expect to drive it.  So I found myself
testing a Cygwin GDB using a customer's Windows-only SDK.  And the
debugger got very, very unhappy because there's a filename comparison
in the dwarf reader; one of the arguments came from the compiler as
"\foo\bar.h" and the other came in two pieces "\foo" and "bar.h".  GDB
assembled that as "\foo/bar.h" and FILENAME_CMP returned false.

For my local testing I wrote a filename comparison function that
allowed windows slashes.  I didn't need to worry about case sensitivity
here, because Windows tools are generally case-preserving unless you
feed them input with strange casing.  This was sort of unpleasant, but
useful.  And in thinking about it, I think I'd rather have this return
true than false:
  FILENAME_CMP ("a\\b", "a/b")

Since almost no one puts backslashes in Unix filenames (they're a
mental health hazard), and having a\\b and a/b is a truly improbable
case.

What do y'all think?  Would a gdb_filename_cmp with this behavior be
OK?

-- 
Daniel Jacobowitz
CodeSourcery