[Bug 1695] bytes_transfered = rtems_rfs_rtems_error

[bugzilla-daemon at rtems.org]

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

--- Comment #11 from Gedare <giddyup44 at yahoo.com> 2010-09-02 16:00:25 CDT ---
(In reply to comment #10)
> (In reply to comment #9)
> > (In reply to comment #8)
> > > (In reply to comment #7)
> > > > (In reply to comment #6)
> > > > > My understanding is that assigning a negative value to
> > > > > bytes_transfered does not make any sense -- unless you are reference counting
> > > > > some bi-directional traffic, you shouldn't have a negative number for a size
> > > > > value.
> > > > 
> > > > This is the API defined by the read handler and it matches the 'read' call's
> > > > API.
> > 
> > Sorry, double clicked the last message (hit reply then commit on accident).
> > 
> > I see that bytes_transfered is set to -1 to indicate an error condition, which
> > is flagged by a positive value of rc.  However, -1 is then returned as a
> > ssize_t, which is an unsigned (opaque) type for storing size values.  I think
> > this is Ralf's complaint about the code being 'dirty'.
> > 
> > I don't know that there is anything worth fixing here though, especially if the
> > API is already in-use.
> 
> ssize_t is signed. size_t is unsigned.
> 
> http://www.opengroup.org/onlinepubs/009695399/basedefs/sys/types.h.html
> 
> size_t shall be an unsigned integer type.
> 
> The type ssize_t shall be capable of storing values at least in the range [-1,
> {SSIZE_MAX}].
> 
> I think bytes_transfeRRed should be ssize_t.  Especially if this is a  "read()"
> system call handler for this filesystem.  read(2) returns ssize_t.
> 
> 
> typedef signed int _ssize_t;

oops, well then I don't really see any badness here. Except the misspelling.

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