On 21 Dec 2011, at 15:31, John Baldwin wrote: > On Tuesday, December 20, 2011 5:18:58 pm m...@freebsd.org wrote: >> On Tue, Dec 20, 2011 at 1:49 PM, John Baldwin <j...@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!). Robert_______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
