Menu
▾
▴
Re: [Iverilog-devel] NULL file descriptor or MCD
|
From: Cary R. <cy...@ya...> - 2020-05-17 18:24:20
|
The other issue I see is if you call $fclose() with a MCD and any of the bits are invalid files none of the files will be closed. This is existing functionality and not something new. It almost seems like we need to pass the MCD to vpi_mcd_close() and then report an failures based on what could not be closed. All other routines that take a MCD also just return with a warning message.
Cary
On Sunday, May 17, 2020, 11:11:22 AM PDT, Cary R. <cy...@ya...> wrote:
Here is example code and what I have implemented for checking the return value of vpi_mcd_close(). The "could not close ..." lines are the new output from checking the close return value. If this is acceptable I will commit this and update the tests as needed.
module top;
integer fd;
initial begin
// MCD
fd = 0;
$fclose(fd); // NULL
fd = 1;
$fclose(fd); // STDOUT
fd = 2;
$fclose(fd); // Invalid
// FD
fd=32'h80000000;
$fclose(fd); // STDIN
fd=32'h80000001;
$fclose(fd); // STDOUT
fd=32'h80000002;
$fclose(fd); // STDERR
fd=32'h80000003;
$fclose(fd); // Invalid
end
endmodule
WARNING: tmp.v:9: could not close MCD STDOUT (0x1) in $fclose().
WARNING: tmp.v:11: invalid MCD (0x2) given to $fclose().
WARNING: tmp.v:15: could not close file descriptor STDIN (0x80000000) in $fclose().
WARNING: tmp.v:17: could not close file descriptor STDOUT (0x80000001) in $fclose().
WARNING: tmp.v:19: could not close file descriptor STDERR (0x80000002) in $fclose().
WARNING: tmp.v:21: invalid file descriptor (0x80000003) given to $fclose().
Cary
On Sunday, May 17, 2020, 2:18:34 AM PDT, Cary R. via Iverilog-devel <ive...@li...> wrote:
Thanks Martin,
That is what is currently implemented except for the fclose() failure. At the moment $fclose() is implemented using vpi_mcd_close(), which now returns the failing MCD/FD correctly. One of the fixes I added is if you try to close the preopened descriptors (STDOUT either MCD or FD along with the STDIN or STDERR FDs) it returns them since they were not closed (it's an error). Should we report an error when trying to close these or just when the underlying fclose() fails? My inclination would be report them
The big-3 simulator I use appears to not report any messages when invalid FD/MCDs are used. I guess a place where we can do things better. I get a failing fclose() is fairly benign, but it seems like giving information regarding bugs would be helpful.
Cary
On Sunday, May 17, 2020, 1:11:27 AM PDT, Martin Whitaker <ic...@ma...> wrote:
A null MCD (empty set) was accepted by the file I/O tasks in Verilog-XL
without any warning. I have used that feature in test benches (including
passing it to $fclose), and would not want a warning.
I'm not against warnings if you pass an invalid FD/MCD to $fclose or
$fclose fails.
On 17/05/2020 03:38, Cary R. via Iverilog-devel wrote:
> And on the subject of $fclose() should it print a warning when you try to close one of the preopened MDC/FDs? Should it print a message if the underlying fclose() fails for some reason? We do cleanup the entry even if it fails so it is no longer available, but vpi_mcd_close() returns the descriptor for any failing items (well it does it correctly now) so we could report underlying issues correctly.
> Cary
>
> On Saturday, May 16, 2020, 4:24:29 PM PDT, Cary R. via Iverilog-devel <ive...@li...> wrote:
>
> It looks like Icarus along with at least one of the Big-3 simulators allows, without warning, the various file I/O system tasks/functions to accept a NULL (0) file descriptor/MCD. I can see this as helpful if you want to disable output by just setting the FD/MCD to zero, but it could be an issue if the $fopen failed and the user did not check so having a warning would be beneficial for that. We do print a warning for an invalid non-zero FD/MCD.
>
> So should a zero FD/MCD print a warning or do we just want it to return as if nothing happened?
> I tend to like the warnings, but I'm not certain if there is an easy way to disable MCD output without using the zero value. Should $fclose be handled differently?
>
> Thoughts/suggestions appreciated.
>
> Thanks,
> Cary
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>
>
>
>
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>
_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel
_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel
|
