• James Dunne (16/16) Dec 18 2004 Walter,
• Simon Buchan (21/46) Dec 18 2004 Since my line no.'s are fine with CR/LF files, I doubt it... but it coul...
• Derek (17/21) Dec 18 2004 These actions hark back to the days of mechanical typewriters / teletype

James Dunne <jdunne4 bradley.edu> writes:

Walter,

I've heard quite a few times that the error reporting feature of the DMD
compiler has line number issues.  I think I may have found why.  If this has
been suggested by someone else, then just ignore me ;).

In the front-end's lexer.c, in both functions Lexer::wysiwygStringConstant (line
864 in v0.109) and Lexer::hexStringConstant (line 917 in v0.109), the character
'\r' is used to also increment the linenumber counter (effectively).  However,
Windows uses CR+LF (\r+\n) in combination to handle a newline, and rendering the
'\r' as a '\n' is not correct.  This would result in adding two lines per each
'\r\n' combination.  This could also explain why the reported line numbers are
usually twice that of the actual line number where the error occurs.

I, myself, don't usually see these errors as I work primarily with D in Linux.
However, I have worked with D in Windows and usually get bogus line numbers.

If this fixes the issue, then I'm glad I could be of assistance.

Regards,
James Dunne

"Simon Buchan" <currently no.where> writes:

On Sat, 18 Dec 2004 09:17:41 +0000 (UTC), James Dunne  
<jdunne4 bradley.edu> wrote:

 Walter,

 I've heard quite a few times that the error reporting feature of the DMD
 compiler has line number issues.  I think I may have found why.  If this  
 has
 been suggested by someone else, then just ignore me ;).

 In the front-end's lexer.c, in both functions  
 Lexer::wysiwygStringConstant (line
 864 in v0.109) and Lexer::hexStringConstant (line 917 in v0.109), the  
 character
 '\r' is used to also increment the linenumber counter (effectively).   
 However,
 Windows uses CR+LF (\r+\n) in combination to handle a newline, and  
 rendering the
 '\r' as a '\n' is not correct.  This would result in adding two lines  
 per each
 '\r\n' combination.  This could also explain why the reported line  
 numbers are
 usually twice that of the actual line number where the error occurs.

 I, myself, don't usually see these errors as I work primarily with D in  
 Linux.
 However, I have worked with D in Windows and usually get bogus line  
 numbers.

 If this fixes the issue, then I'm glad I could be of assistance.

 Regards,
 James Dunne

Since my line no.'s are fine with CR/LF files, I doubt it... but it could  
be
related. (What the heck is the point of BOTH CR AND LF, anyway, seemingly  
apart
 from printing by ASCII output to streams, they have an identical  
meaning...)

-- 
"Unhappy Microsoft customers have a funny way of becoming Linux,
Salesforce.com and Oracle customers." - www.microsoft-watch.com:
"The Year in Review: Microsoft Opens Up"
--
"I plan on at least one critical patch every month, and I haven't been  
disappointed."
- Adam Hansen, manager of security at Sonnenschein Nath & Rosenthal LLP
(Quote from http://www.eweek.com/article2/0,1759,1736104,00.asp)
--
"It's been a challenge to "reteach or retrain" Web users to pay for  
content, said Pizey"
-Wired website: "The Incredible Shrinking Comic"

Derek <derek psyc.ward> writes:

On Sat, 18 Dec 2004 22:29:34 +1300, Simon Buchan wrote:


 (What the heck is the point of BOTH CR AND LF, anyway, seemingly  
 apart
  from printing by ASCII output to streams, they have an identical  
 meaning...)

These actions hark back to the days of mechanical typewriters / teletype
machines. The CR command was sent to the machine to move the print-head
back to the start of the line (Carriage Return) and the LF was sent to move
the roller (and thus the paper) up one line (Line Feed).

One of the needs for having a CR was in order to print BOLD characters, the
print head was moved back to the start of the line, and the bolded
characters were printed over the top of the original characters, thus
effectively printer the characters twice and making them look darker.

Another reason was that the CR was a slow operation (relatively speaking)
and the LF was much faster, so the combination CR LF meant that while the
print head was moving back to the start of the line, the roller could be
moved up a line. So when the print head was ready to print again from the
start of a line, the paper would be already in position.

-- 
Derek
Melbourne, Australia