From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52721) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bSnFJ-0006F9-SQ for qemu-devel@nongnu.org; Thu, 28 Jul 2016 11:29:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bSnFG-0003fG-Kk for qemu-devel@nongnu.org; Thu, 28 Jul 2016 11:29:13 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:10831) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bSnFG-0003fB-C3 for qemu-devel@nongnu.org; Thu, 28 Jul 2016 11:29:10 -0400 Received: from pps.filterd (m0098394.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u6SFP2tG024227 for ; Thu, 28 Jul 2016 11:29:09 -0400 Received: from e06smtp06.uk.ibm.com (e06smtp06.uk.ibm.com [195.75.94.102]) by mx0a-001b2d01.pphosted.com with ESMTP id 24fcm1r7nu-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Thu, 28 Jul 2016 11:29:08 -0400 Received: from localhost by e06smtp06.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 28 Jul 2016 16:29:06 +0100 Received: from b06cxnps4075.portsmouth.uk.ibm.com (d06relay12.portsmouth.uk.ibm.com [9.149.109.197]) by d06dlp02.portsmouth.uk.ibm.com (Postfix) with ESMTP id AD37F219004D for ; Thu, 28 Jul 2016 16:28:30 +0100 (BST) Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com [9.149.37.212]) by b06cxnps4075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id u6SFT4gJ65077476 for ; Thu, 28 Jul 2016 15:29:04 GMT Received: from d06av01.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av01.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id u6SFT3KK019757 for ; Thu, 28 Jul 2016 09:29:03 -0600 References: <1469611466-31574-1-git-send-email-silbe@linux.vnet.ibm.com> <57991CC1.40003@redhat.com> <87twfaysit.fsf@dusky.pond.sub.org> <5799E26B.7090408@linux.vnet.ibm.com> <579A1D33.6010500@redhat.com> From: Halil Pasic Date: Thu, 28 Jul 2016 17:29:02 +0200 MIME-Version: 1.0 In-Reply-To: <579A1D33.6010500@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="F5qAU3lB9PqpeQd6Jq18CFudpm5LHUTBL" Message-Id: <579A24BE.2060707@linux.vnet.ibm.com> Subject: Re: [Qemu-devel] [PATCH] error: error_setg_errno(): errno gets preserved List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake , Markus Armbruster Cc: Sascha Silbe , qemu-devel@nongnu.org, Kevin Wolf , Michael Roth , Cornelia Huck , Max Reitz This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --F5qAU3lB9PqpeQd6Jq18CFudpm5LHUTBL From: Halil Pasic To: Eric Blake , Markus Armbruster Cc: Sascha Silbe , qemu-devel@nongnu.org, Kevin Wolf , Michael Roth , Cornelia Huck , Max Reitz Message-ID: <579A24BE.2060707@linux.vnet.ibm.com> Subject: Re: [Qemu-devel] [PATCH] error: error_setg_errno(): errno gets preserved References: <1469611466-31574-1-git-send-email-silbe@linux.vnet.ibm.com> <57991CC1.40003@redhat.com> <87twfaysit.fsf@dusky.pond.sub.org> <5799E26B.7090408@linux.vnet.ibm.com> <579A1D33.6010500@redhat.com> In-Reply-To: <579A1D33.6010500@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 07/28/2016 04:56 PM, Eric Blake wrote: > On 07/28/2016 04:46 AM, Halil Pasic wrote: >=20 >> The implementation of preserve errno seems inconsistent to me. The >> function error_setv is static, and I guess it is supposed to provide >> this indirect errno preservation and is used for both error_setg und >> error_setg_errno, yet error_setg_ errno_internal does extra save-resto= re >> itself while error_setg_iternal relies on 'indirect', what is not OK i= n >> my opinion. >=20 > As long as errno gets saved where it is documented as saved, I don't > care whether it is direct or indirect (indirect is probably more > efficient, where we can prove that nothing is called that is allowed to= > clobber errno). >=20 It is still inconsistent (error_setg_errno_internal and error_setg_iternal). If it's ok for error_setg_internal to omit saving errno before calling va_start then there is no reason to do it in error_setg_errno_internal. >> >> As Sascha pointed out, in C11 any library functions may change errno >> unless explicitly told otherwise for the particular function. Since >> start_va and end_va has nothing on preserving errno it is guaranteed b= y >> the standard that they persevere errno, and we should assume they don'= t. >=20 > You mean va_start, not start_va. And actually, C11 is clear that errno= > is unspecified after library functions (but not macros) that don't > explicitly state otherwise. Since va_start() is a macro and not a > library function, that means va_start does NOT have carte blanche > permission to modify errno. For more reading on the topic: I also considered this function/macro thing but in the end I am not aware of anything in C11 what would prohibit va_start to modify errno -- correct me if I'm wrong. With that it boils down to 'may' and relying on 'does not' means you are not covered by the standard C11 (but may be covered by something else -- in which case this should be documented in HACKING). >=20 > http://austingroupbugs.net/view.php?id=3D384 > This got rejected, or? Means that there is no willingness to introduce this guarantee at POSIX level? =20 > There are several related POSIX bug reports of other functions that hav= e > been requested to explicitly document that they don't modify errno, and= > I'm happy to submit even more, if we find other standard interfaces > whose semantics are easier when they guarantee that errno is not clobbe= red. >=20 Regards, Halil --F5qAU3lB9PqpeQd6Jq18CFudpm5LHUTBL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iQIcBAEBAgAGBQJXmiS/AAoJEA0vhuyXGx0AtdEP/ApQD0JrhcimU9MCR0aSckDW yAGRwPemhrXCcbLBJlQ8ax3QTl3Ygz7RCROld0qv181i/K+T67Zd2Hfvo+MShPoc hk76SFIRJh338U29M4UgEGMylMw6Rqj07dDkGiJPJtAIjAZioVdfdLneW3b+Wur0 Gyh0Y6mPsir8p5+62gPGgjusjC9lbRY8ABE1pFM38QOkcBZ7DNE2Bovpq4n0WRfn TQK4KTPn3R1w6Aq+0KvluZFXNHjAhB89L9piEMEgZW+in2rFwt+6Gwh8XT4V3ZzJ YJttnLmhFjlITeBVL0Jn8tfvgIDiWiafOhom7NHQ6Ui6o76GiVEM3ReCc+qSawch rxZZP/DAij1YMlTxiaFQpMWj+AYuxrIn3AVaDNfXbueIVw3C/7DvJtM1Iv8n57UR uwprOd5u/tzSus99I/BALt6W8fnJr+1saWS8Mh1o59UqItbzkgz1kgifWqHjNles LFRiCySbUaN0tKmp2eBnIXQE+DPVhWRjNWMAHg1VRBIKBEzUfBoQ1r6FW4d5FluK +IDeqSATc1RZodmadI1IOsKkwcUhxw8QMqLBglyMHMcxpV2mZX3wYljyShhGW+x1 QUDbAkgOky8reOxahdKlmU81zTIYCVLSePmNwiYXKF6HoQefIit/MBQ/IcxBv66u nmG2LTaAzhBNNc/0VBtS =tqFA -----END PGP SIGNATURE----- --F5qAU3lB9PqpeQd6Jq18CFudpm5LHUTBL--