From owner-freebsd-current@FreeBSD.ORG Wed Dec 21 16:02:26 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F8611065676; Wed, 21 Dec 2011 16:02:26 +0000 (UTC) (envelope-from rwatson@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 04CB58FC21; Wed, 21 Dec 2011 16:02:26 +0000 (UTC) Received: from c0144.aw.cl.cam.ac.uk (c0144.aw.cl.cam.ac.uk [128.232.100.144]) by cyrus.watson.org (Postfix) with ESMTPSA id 2BBE546B0D; Wed, 21 Dec 2011 11:02:25 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Robert N. M. Watson" In-Reply-To: <201112211031.11977.jhb@freebsd.org> Date: Wed, 21 Dec 2011 16:02:24 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <955AE804-4517-47ED-9C2A-EDA034BF1CB3@freebsd.org> References: <201112201649.06265.jhb@freebsd.org> <201112211031.11977.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1084) Cc: mdf@freebsd.org, current@freebsd.org Subject: Re: extattr_set_*() return type X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2011 16:02:26 -0000 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 = 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=