Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

camlidl and wrong line/column numbers in error/warning messages (again) #2827

Closed
vicuna opened this issue Jul 3, 2001 · 2 comments
Closed

Comments

@vicuna
Copy link

vicuna commented Jul 3, 2001

Original bug ID: 424
Reporter: administrator
Status: closed
Resolution: fixed
Priority: normal
Severity: minor
Category: -for CamlIDL use https://github.com/xavierleroy/camlidl/issues

Bug description

Full_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 #2773:

  1. 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.

@vicuna
Copy link
Author

vicuna commented Jul 30, 2001

Comment author: administrator

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

@vicuna
Copy link
Author

vicuna commented Jul 30, 2001

Comment author: administrator

Fixed by XL on 2001-07-30.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant