Date: Tue, 31 Aug 2010 23:17:05 +0200 From: Dimitry Andric <dim@FreeBSD.org> To: Kostik Belousov <kostikbel@gmail.com> 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: <4C7D7151.7070001@FreeBSD.org> In-Reply-To: <20100831203358.GD2396@deviant.kiev.zoral.com.ua> References: <201008311811.o7VIBoC5037894@svn.freebsd.org> <20100831195128.GC2396@deviant.kiev.zoral.com.ua> <4C7D61E3.6020409@FreeBSD.org> <20100831203358.GD2396@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2010-08-31 22:33, Kostik Belousov wrote: > 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. Well, I would interpret this as "the null pointer does not point to any object or function". But I am not a native English speaker. > 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. Yes, I completely agree with you. Although even gcc has the warning "NULL used in arithmetic", it apparently does compile such code to what you would expect from it (e.g. wrapping around from address 0x0 to wherever __base is located). But with -ffreestanding there should probably be an exception for this. I will ask the clang guys if it is possible. > I do not see the substraction of two pointers in the changed fragment of code. > :#define PTOV(pa) ((caddr_t)(pa) - __base) > caddr_t is indeed char *, but __base is u_int32_t. Sorry, I interpreted this incorrectly, it is indeed just subtracting an integer from NULL. If you would assume that the null pointer does not point anywhere, adding or substracting integers from it is still undefined, though. :) > 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; Indeed, any subtraction is only in "u_char *p = (u_char *)PTOV(0);". If you prefer, I will revert to the old expression, or maybe we could use John's suggestion of: return (*(u_char *)PTOV(0x401) * 128 * 1024 + *(uint16_t *)PTOV(0x594) * 1024 * 1024); which is less obfuscated.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C7D7151.7070001>