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

Jump to bottom

$fscanf() strange behaviour with carriage return #685

Closed
veripoolbot opened this issue Oct 18, 2013 · 9 comments
Closed

$fscanf() strange behaviour with carriage return #685

veripoolbot opened this issue Oct 18, 2013 · 9 comments
Labels
area: wrong runtime result Issue involves an incorrect runtine result from Verilated model resolution: no fix needed Closed; no fix required (not a bug)

Comments

@veripoolbot
Copy link
Contributor

Author Name: Frederic Requin
Original Redmine Issue: 685 from https://www.veripool.org
Original Date: 2013-10-18

This code does not work:
num = $fscanf(fh, "%d\t%d\t%d\t%d\t%d\t%d\t%d\t%d\n", v_data[0], v_data[1], v_data[2], v_data[3], v_data[4], v_data[5], v_data[6], v_data[7]);
(it should extract 8 tab separated integers from a file)
The file pointer gets positionned 1 char "too far" after the call (it eats up the first char of the next line)

This one works:
num = $fscanf(fh, "%d\t%d\t%d\t%d\t%d\t%d\t%d\t%d", v_data[0], v_data[1], v_data[2], v_data[3], v_data[4], v_data[5], v_data[6], v_data[7]);
ch = $fgetc(fh); // flush carriage return (workaround)

The text file contains carriage returns coded as 0A (unix style) not 0D0A (DOS style).
I use cygwin 32-bit.
@veripoolbot
Copy link
Contributor Author

Original Redmine Comment
Author Name: Frederic Requin
Original Date: 2013-10-18T15:43:15Z

Verilator version used:
$ verilator -version
Verilator 3.851 2013-08-15 rev verilator_3_850-15-gc996d28

@veripoolbot
Copy link
Contributor Author

Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2013-10-18T15:45:08Z

Could you make this into a test_regress/t style test (see the docs and/or edit the existing t_sys_file_basic test) and maybe attempt a fix (see fscan code in include/verilated.cpp)?

@veripoolbot
Copy link
Contributor Author

Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2013-10-29T01:07:04Z

Any luck making a patch?

@veripoolbot
Copy link
Contributor Author

Original Redmine Comment
Author Name: Frederic Requin
Original Date: 2013-10-29T22:38:32Z

Hello,

yes, I can give it a try.

It looks like I have to modify the function _vl_vsscanf() in verilated.cpp.

Maybe also displayEmit() in V3EmitC.cpp (I hope not).

Regards,

Frederic Requin

@veripoolbot
Copy link
Contributor Author

Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2013-11-10T18:24:45Z

I am not able to recreate this on cygwin with either normal or DOS line endings, I will need a patch if it is to be fixed.

@veripoolbot
Copy link
Contributor Author

Original Redmine Comment
Author Name: Frederic Requin
Original Date: 2013-11-21T10:32:41Z

Wilson Snyder wrote:

I am not able to recreate this on cygwin with either normal or DOS line endings, I will need a patch if it is to be fixed.

Hello,
I have tried again with a fresh install of Cygwin64 under Windows 7 64-bit and Verilator 3.852.
Well, it still fails.
This time, I made a regression test, please find it attached.
BTW, how do you handle $stop call in the C++ testbench ? I always get a coredump when $stop is called.

Regards,

Frederic Requin

@veripoolbot
Copy link
Contributor Author

Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2013-11-27T00:20:05Z

I seem to get the same answer (found 31) with other simulators. Are you seeing otherwise?

@veripoolbot
Copy link
Contributor Author

Original Redmine Comment
Author Name: Frederic Requin
Original Date: 2013-11-28T14:48:12Z

I did not check with other simulators. I have 31 without the workaround.

I started googling about the scanf() function in C and it looks like there is a limitation in the handling of carriage return.

Maybe, all of this is related to C scanf()'s fault.

Regards,

Frederic Requin

@veripoolbot
Copy link
Contributor Author

Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2013-11-29T18:23:54Z

Closing, if you find a test that passes on another simulator related to this please reopen or file a new bug with a testcase.

@veripoolbot veripoolbot added area: wrong runtime result Issue involves an incorrect runtine result from Verilated model resolution: nofixneeded resolution: no fix needed Closed; no fix required (not a bug) and removed resolution: nofixneeded labels Dec 22, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
area: wrong runtime result Issue involves an incorrect runtine result from Verilated model resolution: no fix needed Closed; no fix required (not a bug)
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@veripoolbot