www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Line number error reporting compiler issue - solved here?

reply 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
Dec 18 2004
parent reply "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"
Dec 18 2004
parent 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
Dec 18 2004