svn commit: r212064 - head/sys/boot/pc98/boot2

Dimitry Andric dim at
Tue Aug 31 21:17:07 UTC 2010

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

> 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

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

More information about the svn-src-head mailing list