Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 31 Aug 2010 23:33:58 +0300
From:      Kostik Belousov <kostikbel@gmail.com>
To:        Dimitry Andric <dim@freebsd.org>
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
Message-ID:  <20100831203358.GD2396@deviant.kiev.zoral.com.ua>
In-Reply-To: <4C7D61E3.6020409@FreeBSD.org>
References:  <201008311811.o7VIBoC5037894@svn.freebsd.org> <20100831195128.GC2396@deviant.kiev.zoral.com.ua> <4C7D61E3.6020409@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help

--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--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100831203358.GD2396>