From owner-freebsd-scsi@FreeBSD.ORG Fri Oct 4 16:19:52 2013 Return-Path: Delivered-To: FreeBSD-scsi@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 ESMTP id C2F51D9F; Fri, 4 Oct 2013 16:19:52 +0000 (UTC) (envelope-from kostikbel@gmail.com) 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 254112705; Fri, 4 Oct 2013 16:19:51 +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 r94GJlp3090729; Fri, 4 Oct 2013 19:19:47 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r94GJlp3090729 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r94GJlGQ090728; Fri, 4 Oct 2013 19:19:47 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 4 Oct 2013 19:19:47 +0300 From: Konstantin Belousov To: Scott Long Subject: Re: pci_alloc_msi is always called, is this bad? Message-ID: <20131004161947.GU41229@kib.kiev.ua> References: <20131003194704.GG41229@kib.kiev.ua> <1380902209.2621.11.camel@localhost> <94C7BB39-A287-44D4-9992-E8DAE83CE6D4@yahoo.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ImgWj/n5mMvZ1QVT" Content-Disposition: inline In-Reply-To: <94C7BB39-A287-44D4-9992-E8DAE83CE6D4@yahoo.com> User-Agent: Mutt/1.5.21 (2010-09-15) 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: "FreeBSD-scsi@freebsd.org" X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 16:19:52 -0000 --ImgWj/n5mMvZ1QVT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 04, 2013 at 10:05:18AM -0600, Scott Long wrote: > It used to be that gcc would generate code that would conditionally execu= te the second clause only if the first clause were true. If that's not lon= ger the case (with gcc and/or clang), then I bet that UDF will break due to= this: >=20 > /* > * Check to see if the fid is fragmented. The first test > * ensures that we don't wander off the end of the buffer > * looking for the l_iu and l_fi fields. > */ > if (ds->off + UDF_FID_SIZE > ds->size || > ds->off + le16toh(fid->l_iu) + fid->l_fi + UDF_FID_SIZE > ds-= >size){ Is this some sort of joke ? C 'and' and 'or' logical operators are short-circuit. It is not compiler-depended. --ImgWj/n5mMvZ1QVT Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (FreeBSD) iQIcBAEBAgAGBQJSTuqiAAoJEJDCuSvBvK1BpmcP/2jhDRiUqchmjr/iWpJ1Nsbb lIZuwTm+jzd+YV3rmgOHm+HJBX9HkN2jhuRw8lEV0LLw4dpJ39LxbDLcPx+2SX1u lFBzVsIZOObf0d50yqNRofC0sHGrbki2+xV3mEoS1XkLP7W2LN/MdNLpsHo35fOl zQYwfBbeglfT8Lc/ZPbxE/4ViL8RUBL62+dBBw6gwVrkWrNylzO7e5gv0x/CTFcA eT0mtBsswEx4qAo8/hR244vxxAm8eQLjdntGRHPYQj6kwnQwxBg+9NE5IMoA6esT 8fleCrgJIhuBeA/ul1Hz2pDeEj3M7f2cvww3GAKMIQMPppizGRanzYNvMqsL6T08 ZM0RSN7PWPsWIeQktXPO17XvuHkBizIfOESP3ahQVbfZQvRcfsy1+yK4hpawm2/w LPuNEXUrkljeJ34oBPYAzJhQMfNqq1AMsTknpg4TiNMjJtc7jHi3wLcl3FNAMcX/ VlTUk3DumA8yCQ5LOhcldfNaIaOofMK8+JZ8ppxalfis5st32bjeHb0EJzHa5Ndb wZX9ZMJN1ac699DmAXasf7sgTOy2vCUwLGrU6wpG3vNFrshu7c5PKUHnh6ChejnV svSQnVdj1WQnFV4WooH+HFXWydzz+MHJ6YEGsk48IuiHN5TbZpYQ1jE8617Rfjpr atuReiBcAgEXQ6EYCDgw =ZiWM -----END PGP SIGNATURE----- --ImgWj/n5mMvZ1QVT--