cvs commit: hugs98/src input.c

nordland 2001/12/05 16:50:13 PST Modified files: src input.c Log: ***EXPERIMENTAL*** Added support for both \n and \r as line terminators. Works fine under unixen and MacOS 8, but I haven't tried it under WinDOS. It should work, though, as I understand the assumption here is that every CRLF is converted to a single \n before Hugs will ever see any chars. So line numbers should be reported correctly for every combination of platform and linefeed-convention, except for DOS files under unix and MacOS. Would someone (Sigbjorn?) be kind enough to recompile and check this as soon as possible? If there are any problems I'll withdraw this change immediately! One could also consider a more robust scheme, where source files are analyzed to determine their linefeed-convention. But I don't think it's worth the trouble, and my fix will already take care of most examples of cross-platform problems... Revision Changes Path 1.30 +16 -16 hugs98/src/input.c

nordland 2001/12/05 16:50:13 PST
Modified files: src input.c Log: ***EXPERIMENTAL*** Added support for both \n and \r as line terminators. Works fine under unixen and MacOS 8, but I haven't tried it under WinDOS. It should work, though, as I understand the assumption here is that every CRLF is converted to a single \n before Hugs will ever see any chars. So line numbers should be reported correctly for every combination of
It seems to work, but given the amount of bugs & issues the topic
of line termination have been the source of in numerous other
cross-platform systems, my humble opinion is that it would be
prudent not to make this change so close to a new release.
--sigbjorn
----- Original Message -----
From:
and linefeed-convention, except for DOS files under unix and MacOS.
Would someone (Sigbjorn?) be kind enough to recompile and check this as soon as possible? If there are any problems I'll withdraw this change immediately!
One could also consider a more robust scheme, where source files are analyzed to determine their linefeed-convention. But I don't think it's worth the trouble, and my fix will already take care of most examples of cross-platform problems...
Revision Changes Path 1.30 +16 -16 hugs98/src/input.c
_______________________________________________ Cvs-hugs mailing list Cvs-hugs@haskell.org http://www.haskell.org/mailman/listinfo/cvs-hugs

On Wednesday, December 5, 2001, at 10:43 PM, Sigbjorn Finne wrote:
It seems to work, but given the amount of bugs & issues the topic of line termination have been the source of in numerous other cross-platform systems, my humble opinion is that it would be prudent not to make this change so close to a new release.
--sigbjorn
How true! I got a little carried away... Still, I couldn't resist looking at the problem in a bit more depth, and I soon realized that the robust solution wasn't that far away. So I'm going to check in a second variant where I have made the multi-platform linefeed handling conditional (MULTI_LINEFEED). It's currently turned on by default, but I can easily be persuaded to turn it off. However, the fix is pretty simple, it's really useful, and I also claim it's robust. To support that claim I've updated the test suite to test both plain and literate sources in three different newline formats (the last 6 tests in the static suite). This currently works very well on unix and MacOS, but it needs to be checked under Windows as well. Would you be able to verify this? If the test script can be run under Windows, all you have to do is load the files tests/static/Plain*.hs and tests/static/Lit*.lhs, and verify that the line number in the error messages are consistent (lines 6 and 9, respectively). -- Johan
----- Original Message ----- From:
To: Sent: Wednesday, December 05, 2001 16:50 Subject: cvs commit: hugs98/src input.c nordland 2001/12/05 16:50:13 PST
Modified files: src input.c Log: ***EXPERIMENTAL*** Added support for both \n and \r as line terminators. Works fine under unixen and MacOS 8, but I haven't tried it under WinDOS. It should work, though, as I understand the assumption here is that every CRLF is converted to a single \n before Hugs will ever see any chars. So line numbers should be reported correctly for every combination of platform and linefeed-convention, except for DOS files under unix and MacOS.
Would someone (Sigbjorn?) be kind enough to recompile and check this as soon as possible? If there are any problems I'll withdraw this change immediately!
One could also consider a more robust scheme, where source files are analyzed to determine their linefeed-convention. But I don't think it's worth the trouble, and my fix will already take care of most examples of cross-platform problems...
Revision Changes Path 1.30 +16 -16 hugs98/src/input.c
_______________________________________________ Cvs-hugs mailing list Cvs-hugs@haskell.org http://www.haskell.org/mailman/listinfo/cvs-hugs
_______________________________________________ Cvs-hugs mailing list Cvs-hugs@haskell.org http://www.haskell.org/mailman/listinfo/cvs-hugs

"Johan Nordlander"
So I'm going to check in a second variant where I have made the multi-platform linefeed handling conditional (MULTI_LINEFEED). It's currently turned on by default, but I can easily be persuaded to turn it off. However, the fix is pretty simple, it's really useful, and I also claim it's robust.
That makes good sense. I trust your judgement about the default setting. If any issues should arise, rolling a patch & new binary bundles is not much work.
To support that claim I've updated the test suite to test both plain and literate sources in three different newline formats (the last 6 tests in the static suite). This currently works very well on unix and MacOS, but it needs to be checked under Windows as well. Would you be able to verify this? If the test script can be run under Windows, all you have to do is load the files tests/static/Plain*.hs and tests/static/Lit*.lhs, and verify that the line number in the error messages are consistent (lines 6 and 9, respectively).
I tried this under both "cmd.exe" and "bash", and the line numbers come out right. --sigbjorn
participants (3)
-
Johan Nordlander
-
nordland@glass.cse.ogi.edu
-
Sigbjorn Finne