From owner-svn-src-head@FreeBSD.ORG Tue Aug 31 20:34:03 2010 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F099C10656A4; Tue, 31 Aug 2010 20:34:02 +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 72B998FC0C; Tue, 31 Aug 2010 20:34:02 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o7VKXxGo037800 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 31 Aug 2010 23:33:59 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o7VKXwkS018006; Tue, 31 Aug 2010 23:33:58 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o7VKXw9S018005; Tue, 31 Aug 2010 23:33:58 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 31 Aug 2010 23:33:58 +0300 From: Kostik Belousov To: Dimitry Andric Message-ID: <20100831203358.GD2396@deviant.kiev.zoral.com.ua> References: <201008311811.o7VIBoC5037894@svn.freebsd.org> <20100831195128.GC2396@deviant.kiev.zoral.com.ua> <4C7D61E3.6020409@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="MdMUFF6WG8fEME8Z" Content-Disposition: inline In-Reply-To: <4C7D61E3.6020409@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=-2.2 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_50, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r212064 - head/sys/boot/pc98/boot2 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2010 20:34:03 -0000 --MdMUFF6WG8fEME8Z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 31, 2010 at 10:11:15PM +0200, Dimitry Andric wrote: > On 2010-08-31 21:51, Kostik Belousov wrote: > > What is the undefined behaviour you are claiming there ? >=20 > Arithmetic on a NULL pointer, which is undefined. The C standard says > in 6.5.6 (additive operators): >=20 > 3. For subtraction, one of the following shall hold: > ? both operands have arithmetic type; > ? both operands are pointers to qualified or unqualified versions of > compatible object types; or > ? the left operand is a pointer to an object type and the right > operand has integer type. (Decrementing is equivalent to > subtracting 1.) >=20 > But NULL does not point to any specific object. A few paragraphs down > it says: >=20 > 9. When two pointers are subtracted, both shall point to elements of > the same array object, or one past the last element of the array > object; the result is the difference of the subscripts of the two > array elements. >=20 > NULL does not point to anything, so you cannot subtract NULL from a > pointer, nor subtract a pointer from NULL (as is done here). Going into this mode, can you cite the spell that makes the NULL to not point to anything ? There is 6.3.2.3, ---------------------------------------------------- If a null pointer constant is converted to a pointer type, the resulting pointer, called a null pointer, is guaranteed to compare unequal to a pointer to any object or function. ---------------------------------------------------- In other words, any object instantiated by C source code (be it declaration, malloc-kind allocation etc) cannot have address equial to NULL. But this does not make NULL lesser pointer then any other. >=20 > Apparently gcc allows it, possibly as an extension? But clang does not, > and will generate a 'unreachable' instruction for this expression. (I > encountered this when I was trying to get boot2 compiled by clang small > enough to fit in 7168 bytes.) >=20 6.5.6.9 is worded to allow tagged architectures to support ANSI C. Clang behaviour is literalism and very unuseful for freestanding environments on the usual architectures, where whole address space is a single char array. I do not see the substraction of two pointers in the changed fragment of co= de. :#define PTOV(pa) ((caddr_t)(pa) - __base) caddr_t is indeed char *, but __base is u_int32_t. And there seems to be no substraction of pointers in the old version of - return *(p + 0x401) * 128 * 1024 + *(u_int16_t *)(p + 0x594) * 1024 * = 1024; + return *p * 128 * 1024 + *(u_int16_t *)(p + (0x594 - 0x401)) * 1024 * = 1024; --MdMUFF6WG8fEME8Z Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkx9ZzYACgkQC3+MBN1Mb4j3gQCgkmTXNY1gDMZXgv2wbE0xX28n 8J8An1MVGNM0PoMwXs1CkACkyKCEolUR =/C1Z -----END PGP SIGNATURE----- --MdMUFF6WG8fEME8Z--