From owner-freebsd-current@FreeBSD.ORG Wed Dec 21 20:28:48 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 3754B106566B; Wed, 21 Dec 2011 20:28:48 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id BF8288FC08; Wed, 21 Dec 2011 20:28:47 +0000 (UTC) Received: from alf.home (alf.kiev.zoral.com.ua [10.1.1.177]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id pBLKShCm023539 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Dec 2011 22:28:43 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from alf.home (kostik@localhost [127.0.0.1]) by alf.home (8.14.5/8.14.5) with ESMTP id pBLKSh8p078777; Wed, 21 Dec 2011 22:28:43 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id pBLKSg3s078776; Wed, 21 Dec 2011 22:28:42 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 21 Dec 2011 22:28:42 +0200 From: Kostik Belousov To: John Baldwin Message-ID: <20111221202842.GZ50300@deviant.kiev.zoral.com.ua> References: <201112201649.06265.jhb@freebsd.org> <201112211031.11977.jhb@freebsd.org> <20111221161310.GW50300@deviant.kiev.zoral.com.ua> <201112211225.18581.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="D8moR97HX12ax1eu" Content-Disposition: inline In-Reply-To: <201112211225.18581.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: mdf@freebsd.org, Robert Watson , 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 20:28:48 -0000 --D8moR97HX12ax1eu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 21, 2011 at 12:25:18PM -0500, John Baldwin wrote: > On Wednesday, December 21, 2011 11:13:10 am Kostik Belousov wrote: > > On Wed, Dec 21, 2011 at 10:31:11AM -0500, 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 wro= te: > > > > > Hmm, if these functions are expected to operate like 'write(2)' a= nd are > > > > > supposed to return the number of bytes written, shouldn't their r= eturn value > > > > > be 'ssize_t' instead of 'int'? It looks like the system calls th= emselves > > > > > 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 platfor= ms). It > > > > > would seem that the only change would be to the header and probab= ly > > > > > syscalls.master. I guess this would require a symver bump to fix= though. > > > >=20 > > > > An extended attribute larger than 2GB is a programming abuse, thoug= h. > > > > 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 a= buse by > > > some. :) > > >=20 > > > The type should match the documented behavior. On OS X the set opera= tion > > > 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 i= nt, and > > > the 'get' operations already return a ssize_t, not an int. > >=20 > > Note that read(2)/write(2) do return int. I still have WIP patch to fix > > this, but after some conversations with Bruce I am not sure it is worth > > finishing. >=20 > The manpages and /usr/include/unistd.h claim they return ssize_t. Is this > related to the changes to make uio_resid a size_t (I thought that went in= to > the tree)? If the problem is that the values read/write return may fall = into > the range of only an int even on 64-bit platforms, that is different from= the > return type which is part of the ABI. Yes, it is related. The type change for uio was done in advance. Take a look at the first statement of sys_read() and sys_write(): if (uap->nbyte > INT_MAX) return (EINVAL); and at the copyinio(), which is used by scatter/gather versions of i/o syscalls to copy in uiovec: if (iov->iov_len > INT_MAX - uio->uio_resid) { free(uio, M_IOV); return (EINVAL); --D8moR97HX12ax1eu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk7yQXoACgkQC3+MBN1Mb4jaOwCgkR+atYErjar9X+ZbW0IOkyPI tskAoKbp7C/X/oYD5lMUQgB81/vupuME =7385 -----END PGP SIGNATURE----- --D8moR97HX12ax1eu--