[Bug 1695] bytes_transfered = rtems_rfs_rtems_error

[bugzilla-daemon at rtems.org]

https://www.rtems.org/bugzilla/show_bug.cgi?id=1695

--- Comment #14 from Chris Johns <chrisj at rtems.org> 2010-09-03 01:01:06 CDT ---
(In reply to comment #13)
> (In reply to comment #3)
> > > (In reply to comment #1)
> > > > I do not see a problem with this code as 'rtems_rfs_rtems_error' returns 0 or
> > > > -1 depending on the value of 'rc' which in this case is != 0 so
> > > > bytes_transfered is always set to -1.
> > > 
> > > Well, this code might work, however I consider this code to be dirty.
> > 
> > Could you please elaborate ?
> 

Thanks for getting back to this PR.

> I am having two issues with it:
> 
> a) Semantical issues:
> 
> What is the meaning of rtems_rfs_rtems_error()'s returned value/type?
> Is it a ssize_t or an binary error code (0/-1)?

I have checked the RFS code and all but one case (in rtems_rfs_rtems_shutdown)
an error code is being passed so the test for 0 can be removed. This would
resolve the Coverity issue. How the -1 is returned without being a function
becomes difficult so I could remove the macro and just have a function. There
is no performance issues having a call.

Another solution is to not return anything and when no tracing is enabled just
set errno to the passed error code and update the code to explicitly set the -1
value.

I have tried to avoid the method used in the dosfs and IMFS of using
'rtems_set_errno_and_return_minus_one'.

I am happy to follow any recommendations.

> What I also do not understand in this context is rtems_rfs_dir_read():
> AFAIU, it seem to return an error code. This seems inconsistent and
> non-intuitive because read(2) returns ssize_t.

I am not sure how to answer this one because I feel I am missing something. I
assume you know as well as anyone read(2) returns -1 on an error if no data has
been read.

The setting of the variable is to allow a common path out of the function via
the clean up code.

If it is related to 
> 
> 
> b) a functional issue:
> ...
  ....
> ...
> In case of rc != ENOENT and rc >= 0, rtems_rfs_rtems_error ditches
> bytes_transfered (sets it -1), though it has read and processed something.
> I don't understand this.

Good point. I need to change this as it does not comply with the standard. It
states only to return an error indication (-1, and errno set) if nbytes is
equal to 0. The dosfs directory read also does the same thing as well as the
RFS and dosfs file read code. I will fix the RFS code as part of this PR.

-- 
Configure bugmail: https://www.rtems.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.