#577830 Split filenames of $dumpfile and $readmem in amd64

Package:
gplcver
Source:
gplcver
Description:
Verilog simulator
Submitter:
Marco Túlio Gontijo e Silva
Date:
2015-03-27 09:21:10 UTC
Severity:
normal
#577830#5
Date:
2010-04-14 22:46:11 UTC
From:
To:
Hi.

This bug is also reported in: https://bugs.launchpad.net/ubuntu/+source/gplcver/+bug/243980

For instance, using:

$dumpfile("teste-disco.vcd"); // it creates isco.vcd
$dumpfile("disco.vcd"); // it creates isco.vcd
$dumpfile("isco.vcd"); // it creates nothing
$dumpfile("o.vcd"); // it creates nothing

This patch fixes the issue.
#577830#10
Date:
2010-04-15 17:39:37 UTC
From:
To:
Hi.

This patch is causing segmentation fault in other examples, such as the files
in #577934.

Greetings.
#577830#15
Date:
2015-03-26 14:25:49 UTC
From:
To:
---end quoted text---

  The bug reported in LP 243980 is what I am experiencing here (I am
  on an amd64 machine). Yet the symptoms you mentioned are different,
  and I am not able to reproduce it here.

  Actually I realized the following:
  $dumpfile("test.vcd"); // dumps to '.vcd' file
  $dumpfile("test.VCD"); // dumps to '.VCD' file
  $dumpfile("test"); // dumps to 'test' file

  So it seems the problem is with parsing the string which contains a
  dot '.'

  I ran cver through the debugger, I started from src/v_ex.c(4903),
  which calls __get_eval_cstr from src/v_cnv.c.

  In the first case (ie. "test.vcd") the value of `__exprline' variable
  after execution of line src/v_cnv.c:1721 is "\0\0\0\0.vcd" !
  So for some reason, the characters before the dot are converted to
  nulls !
  Also the value of `xsp->xslen' is 64 after execution of line
  src/v_cnv.c:1715

  In the third case (ie. "test") the value of `__exprline' variable
  after execution of line src/v_cnv.c:1721 is "test", and the value of
  `xsp->xslen' is 32 after execution of line src/v_cnv.c:1715

  I will try to investigate further
#577830#20
Date:
2015-03-26 14:29:08 UTC
From:
To:
---end quoted text---

  From what I mentioned in previous investigation, I think your patch
  seems irrelevant, as the issue doesn't seem to be about size of some
  datatype.

  As of it causing seg. faults with the files in #577943, well, the
  files in that other bug are causing seg. fault even without the patch.
#577830#25
Date:
2015-03-27 09:16:35 UTC
From:
To:
---end quoted text---

  Further tests showed me that I was wrong:

  $dumpfile("test1234"); // dumps into 1234

  So for some reason, it sometimes takes only the last 4 chars of the
  string !

  As for those tests:

  $dumpfile("isco.vcd");
  $dumpfile("o.vcd");

  They actually dump into '.vcd' file (ie. not nothing).