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

See ETF 80.

Shalom

> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On
> Behalf Of Steven Sharp
> Sent: Friday, March 17, 2006 1:58 AM
> To: btf@boyd.com; sv-bc@eda.org
> Subject: [sv-bc] Problem with $ferror in 1364 standard
> 
> 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.