Re: extattr_set_*() return type

On Wednesday, December 21, 2011 11:02:24 am Robert N. M. Watson wrote:
> 
> On 21 Dec 2011, at 15:31, John Baldwin wrote:
> 
> > On Tuesday, December 20, 2011 5:18:58 pm mdf_at_freebsd.org wrote:
> >> On Tue, Dec 20, 2011 at 1:49 PM, John Baldwin <jhb_at_freebsd.org> wrote:
> >>> Hmm, if these functions are expected to operate like 'write(2)' and are
> >>> supposed to return the number of bytes written, shouldn't their return value
> >>> be 'ssize_t' instead of 'int'?  It looks like the system calls themselves
> >>> already do the right thing in setting td_retval[] (they assign a ssize_t to it
> >>> and td_retval[0] can hold a ssize_t on all of our current platforms).  It
> >>> would seem that the only change would be to the header and probably
> >>> syscalls.master.  I guess this would require a symver bump to fix though.
> >> 
> >> An extended attribute larger than 2GB is a programming abuse, though.
> >> Technically int may not be 32 bits but it is on all supported
> >> platforms now.
> > 
> > Today it is an abuse.  In the 90's a 64-bit off_t was considered an abuse by
> > some. :)
> > 
> > The type should match the documented behavior.  On OS X the set operation
> > doesn't return a size but instead returns a simple success/failure (0 or -1)
> > for which an int is appropriate.  However, the FreeBSD API documents that it
> > operates like write and consumes the buffer.   Note that the size of the
> > buffer passed to the 'set' and 'get' operations is a size_t, not an int, and
> > the 'get' operations already return a ssize_t, not an int.
> 
> 
> Using an int was probably a bug. If we can switch to a ssize_t without undue disruption, it seems worthwhile to do so. There was never EA API 
standardisation, and it might be worth pondering whether to pick up additional API variants matching Mac OS X or Linux (note that they differ from 
each other even!).

I think the system call already returns a ssize_t, so the only real change would be
to change the header and bump the symver in userland leaving the old versions as
still returning an int.  I'm not even sure if that is strictly necessary or if we
could get away with just changing the header and be done with it.

-- 
John Baldwin