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

Verilog::Parser (* causes error #403

Closed
veripoolbot opened this issue Oct 25, 2011 · 8 comments
Closed

Verilog::Parser (* causes error #403

veripoolbot opened this issue Oct 25, 2011 · 8 comments
Assignees

Comments

@veripoolbot
Copy link
Collaborator


Author Name: Walter Lavino
Original Redmine Issue: 403 from https://www.veripool.org
Original Date: 2011-10-25
Original Assignee: Wilson Snyder (@wsnyder)


Wilson,

( I am using the CPAN Verilog::Parser (+ Verilog::SigParser) )
In my verilog code, I had this statement.
always @ (* ) begin // {
...
end // }

This caused the parser, to see the always parameters
as a comment ( due to space found after the asteriks), than reading until the end of the file and than
calling the $parser->eof() method and
from here it seems exiting the program with message:

"
%Error: filename.v:211: EOF in (*
fatal flex scanner internal error--end of buffer missed
"

However since I am calling the parser in a loop on multiple files
I would like to have the control when the parser actually exits.
Is there anyway or any callback with which I could avoid the exit of my program
and for me to continue my loop ?

So calling the parser like:

$parser->parse_file (shift);
print STDERR "AA\n";

would not print AA

thanks and regards,
Walo

@veripoolbot
Copy link
Collaborator Author


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2011-10-25T14:15:41Z


[Usage]

On this or most errors, the parser calls the error callback, which defaults (Parser.pm's error) to calls croak. You can thus make your own error callback and override this behavior.

@veripoolbot
Copy link
Collaborator Author


Original Redmine Comment
Author Name: Walter Lavino
Original Date: 2011-10-25T15:45:46Z


Wilson,
I had already overriden the error callback ( and disabled the croak), but flex seems to exit
with message

fatal flex scanner internal error--end of buffer missed

when returning from the error callback.
I had made a trial by overriding the 'eof' callback, which made the process
to continue ( so ignoring the flex error ), but calling the SUPER::eof() ( ie. Verilog::Parser::eof )
also exited the program.

regards,
Walter

@veripoolbot
Copy link
Collaborator Author


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2011-10-25T16:13:07Z


I poked around a bit trying to fix this, but flex (the lexical analyzer which gives the error) doesn't allow a program to put "back" an EOF so it will be seen later. So unfortunately you won't be able to scan again so if you really want to be bullet proof, you'll need to call your parser under a fork() as a child.

@veripoolbot
Copy link
Collaborator Author


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2011-10-25T21:56:10Z


As for the "@(* )" this seems to be legal, and fixed in git towards next release 3.313.

@veripoolbot
Copy link
Collaborator Author


Original Redmine Comment
Author Name: Walter Lavino
Original Date: 2011-10-26T07:35:48Z


Wilson,

Thanks for future fix.

As for the fatal exit, I will use a fork/child solution.
( However still strange flex decides to exit and not return user control.)

regards,
Walter

@veripoolbot
Copy link
Collaborator Author


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2011-11-27T15:45:25Z


In Verilator 3.830.

@veripoolbot
Copy link
Collaborator Author


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2011-11-27T15:46:04Z


Still only resolved, not in Verilog-Perl yet.

@veripoolbot
Copy link
Collaborator Author


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2011-12-14T14:33:16Z


In 3.313.

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

No branches or pull requests

2 participants