RE: [sv-bc] Problem with $ferror in 1364 standard

Hello all,

We also favor interpretation #4.

A bit more clarification:
We propose that the status of the most recent $fopen,
whether success or failure, shall be returned if a
null fd is passed to $ferror.  That seems most intuitive
and useful.

Regards,
Doug Warmke

P.S.  For some reason this dialogue isn't reaching my Inbox,
      although I see it on the email archives.  Other SV-BC
      dialogues are coming through just fine.

> 
>> From: "Bresticker, Shalom" <shalom.bresticker@intel.com>
>>
>> See ETF 80.
> 
> Thanks!
> 
> This became Mantis item 1007.  What comments are there seem to support
> my interpretation 4.
> 
> Steven Sharp
> sharp@cadence.com
> 
> Steven Sharp wrote:
>> The definition of $ferror in section 17.2.7 of the 1364 LRM is
unclear,
>> and may be incorrect or incomplete.
>> 
>> The text refers to an error in "the most recent file I/O operation".
>> This appears to be wrong.  Like the C ferror() function, $ferror is
>> passed a file descriptor argument.  This implies that it returns the
>> most recent error *for that file descriptor*, like ferror() does.
>> If the intent was to return the error for the most recent file I/O
>> operation on any file, there would be no need for such an argument.
>> So the text should be clarified to say "the most recent file I/O
>> operation on the file descriptor fd".
>> 
>> However, this does not provide a way to find out the reason for an
>> error in $fopen.  If $fopen fails, it returns a null file descriptor.
>> Without a file descriptor, $ferror has no information about what
>> file you want the last error for.  In C, you cannot use ferror() to
>> find out the reason for a failure in fopen().  You have to check
>> errno instead.  Verilog does not provide this alternate mechanism.
>> 
>> Note that 17.2.1 talks about errors in $fopen, and then says that
>> "Applications can call $ferror to determine the cause of the most
>> recent error (see 17.2.7)."  This implies that $ferror can be used
>> to find out the cause of a failure in $fopen.
>> 
>> This leaves various possible interpretations:
>> 
>> 1. The implication in 17.2.1 is incorrect, and you cannot use $ferror
>>    to find out the cause of a failure in $fopen.  Since there is no
>>    alternate mechanism for finding out the cause of the failure, this
>>    seems bad.
>> 
>> 2. The syntax in 17.2.7 is incorrect, and there is no fd argument to
>>    $ferror.  $ferror always reports the status of the most recent
file
>>    I/O operation on any file and there is no mechanism for finding
out
>>    the status on a particular file descriptor.  This may not be bad
>>    as long as you always check status immediately after an error,
though
>>    it does not match C as you would expect.
>> 
>> 3. Like interpretation 2, but the syntax is correct and there is a
>>    completely useless fd argument to $ferror.  This would be stupid.
>> 
>> 4. You can use $ferror on a file descriptor to get the most recent
file
>>    I/O status on that file descriptor.  If you pass a null
descriptor,
>>    it is assumed to have come from a failed $fopen, and the status of
>>    the last $fopen (or the last failed $fopen) is returned instead.