From owner-freebsd-standards@FreeBSD.ORG Thu Jan 30 17:52:37 2014 Return-Path: Delivered-To: standards@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9D35FB16; Thu, 30 Jan 2014 17:52:37 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3D6F3148D; Thu, 30 Jan 2014 17:52:37 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id s0UHqTN1085998; Thu, 30 Jan 2014 19:52:29 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s0UHqTN1085998 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id s0UHqQEd085997; Thu, 30 Jan 2014 19:52:26 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 30 Jan 2014 19:52:26 +0200 From: Konstantin Belousov To: Bruce Evans Subject: Re: standards/186028: incorrect return values for posix_fallocate() Message-ID: <20140130175226.GW24664@kib.kiev.ua> References: <201401230858.s0N8wwQB039907@oldred.freebsd.org> <20140123094017.GH24664@kib.kiev.ua> <20140124181246.GO24664@kib.kiev.ua> <20140125062048.R1518@besplex.bde.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lGQpFNrcSq0Rb43w" Content-Disposition: inline In-Reply-To: <20140125062048.R1518@besplex.bde.org> User-Agent: Mutt/1.5.22 (2013-10-16) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: Gennady Proskurin , mdf@freebsd.org, standards@freebsd.org, jhb@freebsd.org X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 17:52:37 -0000 --lGQpFNrcSq0Rb43w Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jan 25, 2014 at 06:46:16AM +1100, Bruce Evans wrote: > I think it is better to not preserve errno, but to intentionally clobber > it to the same value as madvise() does. Its value is unspecified, and > it is better to set it to new garbage than old garbage in case the > application doesn't understand POSIX's suprising error handling. This > follows from C's specification of errno and POSIX's not saying anything > about errnor for posix_madvise(). From a C99 draft: >=20 > [#3] The value of errno is zero at program startup, but is > never set to zero by any library function.159) The value of > errno may be set to nonzero by a library function call > whether or not there is an error, provided the use of errno > is not documented in the description of the function in this > International Standard. >=20 > So any library function can set errno to any nonzero value other than > 0, unless it is specifically documented to not do so. stdio > (__smakebuf()) setting errno to ENOTTY on success in most cases (by > calling isatty() on a non-terminal) a classic example, and > posix_madvise() should be no different, with more reason than stdio. >=20 > In the above, you preserve errno on failure but don't explicitly > preserve it on sucess. madvise() doesn't clobber it on success, but > this is an implementation detail. For most functions, errno becomes > garbage on success. Yes, this is question of quality. posix_madvise(2) should behave like a syscall. > The man pages emphasize not setting errno too much. This matches your > implementation (assuming the undocmented behaviour that madvise() doesn't > modify errno on success), but applications shouldn't depend on this. I document the implementation. If somebody could provide the better wording, I cannot object. For now, I am going to commit the existing patch. --lGQpFNrcSq0Rb43w Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJS6pFZAAoJEJDCuSvBvK1BRb0P/3Nvu7eXvK0+RfkOOUfZBuOc SHSCbkjahEUw/VqiWXR96yLsHVSqhZFdEfObkG9IY3ErNElGNT4/ifJrMjrfxuUX drfTK48DL8tkNE1YfzBK2qwsB1FUWo1ZxB89cqOhV5GZ49cUnivtV88G22NYXw5z 8tsjpyJEgTrl7pUDlaAzB99/9Lr7000jTIhGYG9eRTtede+Jes/uybChDeQHoso0 ilrLYenhVB0blsvvks8kzIK5bkCSPsWQh4515lhID/ERL0H8a1zr32HGYncEkZ1g HliyF0FevrfuscYtsIMwbXOkfbUR07LO8qxWXeMZ/rWR7PWxO9kdimnnvBRhNE4z 4vXMCQ0kxdlEHHbEKrc+1O1geVsBuZZ7cnNP4VPw5wDuRmF/F8w/S7XG3BHXK9B6 +HsdQi6yxBFnLR3YqZE6MLg81FVtWMUP8X33yjuMC+aADUR2K3W2IOHOHvixiKFB 8LQ06oxARKvKQ6/38JjMXvLBoyZt6oiYmuqDIDaNRHcD+40vdqKxCtOZz+PwNPnm 20q1N0AXkO8WX5b4S31xWSPR/GDkp6Rwjl9KVaAqjbOErgZdMqriNT616PBR3kvN 2XWuIeZTieg1OewKgycHucbK0roAuB3+Wsp0aFSHIdUGceVsaB/W01CRf0qHXDRs a5EZfH4GyDyzEWJ0J9Mx =CjaO -----END PGP SIGNATURE----- --lGQpFNrcSq0Rb43w--