Date: Wed, 21 Dec 2011 16:02:24 +0000 From: "Robert N. M. Watson" <rwatson@freebsd.org> To: John Baldwin <jhb@freebsd.org> Cc: mdf@freebsd.org, current@freebsd.org Subject: Re: extattr_set_*() return type Message-ID: <955AE804-4517-47ED-9C2A-EDA034BF1CB3@freebsd.org> In-Reply-To: <201112211031.11977.jhb@freebsd.org> References: <201112201649.06265.jhb@freebsd.org> <CAMBSHm-6VpY_8BkkSJyDThw3DwioaSvC=soZQqcYDAE3jh3oqA@mail.gmail.com> <201112211031.11977.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 21 Dec 2011, at 15:31, John Baldwin wrote: > On Tuesday, December 20, 2011 5:18:58 pm mdf@freebsd.org wrote: >> On Tue, Dec 20, 2011 at 1:49 PM, John Baldwin <jhb@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. >>=20 >> 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. >=20 > Today it is an abuse. In the 90's a 64-bit off_t was considered an = abuse by > some. :) >=20 > 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=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?955AE804-4517-47ED-9C2A-EDA034BF1CB3>