[Bug 1695] bytes_transfered = rtems_rfs_rtems_error

[bugzilla-daemon at rtems.org]

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

--- Comment #13 from Ralf Corsepius <ralf.corsepius at rtems.org> 2010-09-02 23:10:40 CDT ---
(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 ?

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)?

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.


b) a functional issue:
...
  bytes_transfered = 0;

  for (d = 0; d < count; d++, dirent++)
  {
    size_t size;
    rc = rtems_rfs_dir_read (fs, &inode, iop->offset, dirent, &size);
    if (rc == ENOENT)
    {
      rc = 0;
      break;
    }
    if (rc > 0)
    {
      bytes_transfered = rtems_rfs_rtems_error ("dir_read: dir read", rc);
      break;
    }
    iop->offset += size;
    bytes_transfered += sizeof (struct dirent);
...
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.

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