Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000424OCamlCamlIDLpublic2001-07-03 19:512001-07-30 16:26
Reporteradministrator 
Assigned To 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0000424: camlidl and wrong line/column numbers in error/warning messages (again)
DescriptionFull_Name: Dmitry Bely
Version: 3.01, camlidl current cvs
OS: Windows NT 4.0
Submission from: d032.p3.col.ru (195.210.132.32)


from PR#374:

> > 4. In case of syntax error Camlidl sometimes points at the wrong
> > place (sometimes far away from the real place if .idl file is big
> > enough). Here is an example:

> That's a general problem with Yacc parsers: they can shift quite a lot
> of text before getting stuck and reporting an error. So, I haven't
> addressed this issue.

I still believe the bug is in your code. Here is the more expressive example:

[---cut---]
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
// (20 times)

/* line 22 */ abracadabra /* File wrongnum.idl, line 11, column 1: syntax error
*/
[---cut---]

I don't see how extra parser shifts can cause that ... If yacc detects error too
late, reported line should be greater than the real one (obviously not the case
here). Note also column number, that is far from reality.

TagsNo tags attached.
Attached Files

- Relationships

-  Notes
(0000049)
administrator (administrator)
2001-07-30 16:25

> I still believe the bug is in your code. Here is the more expressive example:
>
> [---cut---]
> //
> //
> //
> //
> //
> //
> //
> //
> //
> //
> //
> //
> //
> //
> //
> //
> //
> //
> //
> // (20 times)
>
> /* line 22 */ abracadabra /* File wrongnum.idl, line 11, column 1: syntax error
> */
> [---cut---]
>
> I don't see how extra parser shifts can cause that ...

Granted. There was indeed something wrong in camlidl: it used to read
its input in "text" mode, not "binary" mode, causing character
positions to be mis-computed. Now, the line reported is correct,
however the column is still wrong because it refers to the file after
preprocessing, which is something like

(22 blank lines)
 abracadabra

However, camlidl -nocpp gives the correct location.

- Xavier Leroy

(0000050)
administrator (administrator)
2001-07-30 16:26

Fixed by XL on 2001-07-30.

- Issue History
Date Modified Username Field Change
2005-11-18 10:13 administrator New Issue


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker