🚀 go-pugleaf

>>	char	p[50];
>>	main()
>>	{
>>		printf("p = 0x%08X\n", p);
>>		if (p)
>>			printf("ok\n");
>>		else
>>			printf("bad berries\n");
>
>It seems that your interpretation of what "p" is changes from statement to 
>statement.  In the printf(), p is interpreted as a hexadecimal number,

OK, how else would you print an address on a 68K-based machine,
especially if you don't yet have "%p" in your "printf" implementation? 
(Since he said it's "Mot SVR2 based", I'm assuming it it's a 68K, and
doesn't have "%p".)

>and you are actually printing the address of p.

Yeah, I think he knows that (which is probably why he's using "%08X",
which is appropriate for a 32-bit address, rather than "%02X", which
might be more appropriate for an 8-bit "char").

>Chapter 4.3: "when an array name appears as an argument to a function, the
>location of the beginning of the array is passed")

Yup, and it happens in almost all other contexts, too - including the
expression in an "if" statement....

>At a guess:
>In the if() test you are looking at (probably) the hi order byte represented
>by the address of p[0];   this appears to be 0x0000.  

No, he's looking at the address of "p" itself; the *compiler* might be
generating code to "look at the high order byte represented by the
address of p[0]", but if it is, it's broken.

	if (p)

is, in C, equivalent to

	if (p != 0)

which, at least for "p" of pointer type, is equivalent to

	if (p != NULL)

and any compiler that *doesn't* treat them equivalently is broken.