DOS line endings

DOS line endings

[Zack Weinberg]

These files have DOS line endings on both mainline and 3.3 branch:

boehm-gc/BCC_MAKEFILE
boehm-gc/digimars.mak
boehm-gc/ltmain.sh

gcc/fixinc/tests/base/testing.h
gcc/testsuite/g++.dg/template/member.C
gcc/testsuite/gcc.c-torture/execute/20011126-1.c

libjava/org/w3c/dom/ranges/DocumentRange.java
libjava/org/w3c/dom/ranges/Range.java
libjava/org/w3c/dom/ranges/RangeException.java
libjava/org/w3c/dom/Attr.java
libjava/org/w3c/dom/CDATASection.java
libjava/org/w3c/dom/CharacterData.java
libjava/org/w3c/dom/Comment.java
libjava/org/w3c/dom/DOMException.java
libjava/org/w3c/dom/DOMImplementation.java
libjava/org/w3c/dom/Document.java
libjava/org/w3c/dom/DocumentFragment.java
libjava/org/w3c/dom/DocumentType.java
libjava/org/w3c/dom/Element.java
libjava/org/w3c/dom/Entity.java
libjava/org/w3c/dom/EntityReference.java
libjava/org/w3c/dom/NamedNodeMap.java
libjava/org/w3c/dom/Node.java
libjava/org/w3c/dom/NodeList.java
libjava/org/w3c/dom/Notation.java
libjava/org/w3c/dom/ProcessingInstruction.java
libjava/org/w3c/dom/Text.java
libjava/org/w3c/dom/traversal/DocumentTraversal.java
libjava/org/w3c/dom/traversal/NodeFilter.java
libjava/org/w3c/dom/traversal/NodeIterator.java
libjava/org/w3c/dom/traversal/TreeWalker.java
libjava/testsuite/libjava.compile/OperatorBenchmark.java

I am going to strip the \r characters from the files in the gcc
subdirectory.  I would appreciate a second opinion on the boehm-gc and
libjava files.  It's possible that they are necessary on BCC_MAKEFILE
and digimars.mak.  They are certainly not necessary in libjava, but
I'm guessing that the org/w3c/dom files come from an external source,
and stripping them might make it harder to import newer versions of
these files - Thoughts?

zw

Re: DOS line endings

[Anthony Green]

On Tue, 2003-04-22 at 16:37, Zack Weinberg wrote:
> I'm guessing that the org/w3c/dom files come from an external source,
> and stripping them might make it harder to import newer versions of
> these files - Thoughts?

Correct.  The libjava/org/w3c files come verbatim from the W3C.  I don't
recommend changing them.

AG

Re: DOS line endings

[Tom Tromey]

>>>>> "Zack" == Zack Weinberg <zack@codesourcery.com> writes:

Zack> These files have DOS line endings on both mainline and 3.3 branch:

Zack> boehm-gc/BCC_MAKEFILE
Zack> boehm-gc/digimars.mak
Zack> boehm-gc/ltmain.sh

I don't know what the deal is with ltmain.sh.  I wouldn't expect that
one to have DOS line endings.

Most of the other files in boehm-gc come from an external source.  I'd
prefer we not change them here, as we do import new versions from time
to time.

I've CC'd Hans; he probably knows whether this is required or not.
Anyway, this is the sort of thing in the GC that I prefer we fix
upstream first.  Ordinarily we only put bug fixes in our tree (in
parallel with upstream); more minor stuff comes in via imports.

Zack> libjava/testsuite/libjava.compile/OperatorBenchmark.java

Please do fix this one.  All our line ending tests are in Jacks and
don't appear in the gcc tree at all.

I'm with Anthony about org.w3c.* -- we just leave those alone.

Tom

Re: DOS line endings

[Ranjit Mathew]

> Zack> These files have DOS line endings on both mainline and 3.3 branch:
> 
> Zack> boehm-gc/BCC_MAKEFILE
> Zack> boehm-gc/digimars.mak

I don't know about the Digital Mars compiler, but at least
Borland C/C++ 5.5 works fine with a Makefile (and source
files) that has UNIX line endings.

However...


> Most of the other files in boehm-gc come from an external source.  I'd
> prefer we not change them here, as we do import new versions from time
> to time.

Agreed.

Do DOS line endings cause any problems that you wish to remove them?

Or is it just for the sake of aesthetics? :-)

I ask this because if one were to edit "BCC_MAKEFILE" for some reason
and see its effects, it will have to be in a Win32 environment where 
having DOS line endings is the most natural thing. Simple editors
like "Notepad" on Windows do not take very kindly to UNIX line
endings.

My 2p.

Ranjit. 

Re: DOS line endings

[Zack Weinberg]

"Ranjit Mathew" <rmathew4lists@hotmail.com> writes:

>> Most of the other files in boehm-gc come from an external source.  I'd
>> prefer we not change them here, as we do import new versions from time
>> to time.
>
> Agreed.
>
> Do DOS line endings cause any problems that you wish to remove them?
>
> Or is it just for the sake of aesthetics? :-)

I did run into a problem earlier today.  The short version is that
certain proprietary and far too clever for their own good version
control systems consider that a file that originally had Unix line
endings must have them forever and ever, world without end, amen, and
if you try to check in a new version of the file that's unchanged but
for acquiring DOS line endings, it will say "You didn't change
anything!  I refuse to check this in!"  This causes headaches for
automatic scripts attempting to track a CVS repository in this
system.

But it doesn't seem to mind files that have always had DOS line
endings.

zw

Re: DOS line endings

[Joseph S. Myers]

On Tue, 22 Apr 2003, Zack Weinberg wrote:

> These files have DOS line endings on both mainline and 3.3 branch:

If you want to clean this sort of thing up in general, there may be some
text files in the source tree which lack a newline at the end of the last
line.  Then there are files with excess invisible trailing whitespace on
some of their lines - I expect some people would object to fixing those on
the basis of it causing trouble for merging patches and for cvs annotate,
but when that sort of thing isn't fixed explicitly it gets fixed
accidentally when someone edits one of those files and their editor
removes the whitespace, causing the changes to appear in some other
commit, which is more confusing.  (Of course all these things - DOS line
endings, missing final newlines, trailing whitespace - should be preserved
where deliberate in the CPP testsuite, but not elsewhere.)

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: DOS line endings

[Mike Stump]

On Tuesday, April 22, 2003, at 10:31 PM, Zack Weinberg wrote:
> The short version is that
> certain proprietary and far too clever for their own good version
> control systems consider that a file that originally had Unix line
> endings must have them forever and ever, world without end, amen, and
> if you try to check in a new version of the file that's unchanged but
> for acquiring DOS line endings, it will say "You didn't change
> anything!  I refuse to check this in!"  This causes headaches for
> automatic scripts attempting to track a CVS repository in this
> system.

There is an option to force it, use that option.

RE: DOS line endings

[Boehm, Hans]

The version of ltmain.sh in my tree does not have DOS line endings.  Since some of the configury is likely to remain a bit different in the two versions, and the version in my tree may not automatically be imported, I wouldn't object to changing that one in the gcc tree.  I suspect it acquired the DOS line endings by accident sometime back.

I would be inclined to leave the other two (BCC_MAKEFILE and digimars.mak) as they are.  These files are only usable on Windows, and not used by the build inside gcc.  I would guess that the corresponding versions of make (Borland and Digital Mars) will handle either format, but editors like notepad don't.

Hans

> -----Original Message-----
> From: Tom Tromey [mailto:tromey@redhat.com]
> Sent: Tuesday, April 22, 2003 9:26 PM
> To: Zack Weinberg
> Cc: gcc@gcc.gnu.org; java@gcc.gnu.org; Hans.Boehm@hp.com
> Subject: Re: DOS line endings
> 
> 
> >>>>> "Zack" == Zack Weinberg <zack@codesourcery.com> writes:
> 
> Zack> These files have DOS line endings on both mainline and 
> 3.3 branch:
> 
> Zack> boehm-gc/BCC_MAKEFILE
> Zack> boehm-gc/digimars.mak
> Zack> boehm-gc/ltmain.sh
> 
> I don't know what the deal is with ltmain.sh.  I wouldn't expect that
> one to have DOS line endings.
> 
> Most of the other files in boehm-gc come from an external source.  I'd
> prefer we not change them here, as we do import new versions from time
> to time.
> 
> I've CC'd Hans; he probably knows whether this is required or not.
> Anyway, this is the sort of thing in the GC that I prefer we fix
> upstream first.  Ordinarily we only put bug fixes in our tree (in
> parallel with upstream); more minor stuff comes in via imports.
> 
> Zack> libjava/testsuite/libjava.compile/OperatorBenchmark.java
> 
> Please do fix this one.  All our line ending tests are in Jacks and
> don't appear in the gcc tree at all.
> 
> I'm with Anthony about org.w3c.* -- we just leave those alone.
> 
> Tom
>