🚀 go-pugleaf

>Has anyone isolated the following pcc2 bug?  (I assume it is a bug.)
>We have a Mot SVR2 based compiler.
>	char	p[50];
>	main()
>	{
>		printf("p = 0x%08X\n", p);
>		if (p)
>			printf("ok\n");
>		else
>			printf("bad berries\n");
>	}
>When run, this it says:
>	p = 0x00002F84
>	bad berries
>Any pointers?

It seems that your interpretation of what "p" is changes from statement to 
statement.  In the printf(), p is interpreted as a hexadecimal number, and
you are actually printing the address of p. (see "The C Programming Language",
Chapter 4.3: "when an array name appears as an argument to a function, the
location of the beginning of the array is passed")


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.  

Do you really want to check to ensure that there is a value stored at &p[0]?
( if(p[0])  ) or do you want to ensure you have an array ( if(p != NULL) )

Dan Suthers, Systems Analyst;

->	char	p[50];
->		if (p)
->			printf("ok\n");
->		else
->			printf("bad berries\n");
->	bad berries

In article <24971@pbhya.PacBell.COM> dbsuther@PacBell.COM
(Daniel B. Suthers) writes:
-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.  
-
-Do you really want to check to ensure that there is a value stored at &p[0]?
-( if(p[0])  ) or do you want to ensure you have an array ( if(p != NULL) )

He really wants `if (p!=NULL)', which is what `if (p)' *means*!
It *is* a compiler bug.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris

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

Somebody complained that his Motorola Unix compiler miscompiles the following:
>>	char	p[50];
>>	main()
>>	{
>>		printf("p = 0x%08X\n", p);
>>		if (p)
>>			printf("ok\n");
>>		else
>>			printf("bad berries\n");

Yes, indeed, it is a compiler bug.

Motorola's c compiler is broken in many, many places.  Don't hold your 
breath waiting for fixes unless you are particularly fond of cyanosis. 

I have been trying for over two years to get a working compiler out of 
Motorola. 

I have submitted many bug reports to Motorola, with many bugs shown in 
excruciating detail.  I have annotated hundreds of lines of assembly code. 
My compiler will not produce working 68881 code.  It will not properly 
compile the statement: 

p && free(p);

I reported an assembler bug.  I included the original C code, the compiler 
output, and a typescript of a debugger session in which I demonstrated the 
circumstances under which as would generate an incorrect branch 
displacement.  An "engineer" eventually informed me that there was no bug, 
that the assembler was functioning correctly.  I was comforted only 
momentarily, however, since the machine persisted in reporting an illegal 
instruction immediately after the branch was executed. 

I spent around 150 hours trying to produce a working gcc binary with the
Motorola compiler.  Unfortunately, it miscompiles the output of genrecog.c.
I finally gave up in disgust.


I submitted bug reports during the original warranty period, and refused 
to purchase a service contract until a working compiler was delivered.  I 
have spent many, many hours talking to many, many Motorola employees.  
Said employees are uniformly polite, eager to help, and produce very 
little that is of any use to me.  They do not follow up on their promises.  
They do not test their products (I was delivered a compiler and a long 
list of "bug fixes."   It would not compile all of the test programs 
included with the original bug reports which it claimed to answer). 

I eventually did purchase a service contract to avoid an exorbitant repair 
bill for a failed disk controller.  They refused to sell the hardware 
contract without the software contract.  Of course, as might be expected, 
they have displayed absolutely no inclination to honor the software 
contract. 
-- 
 kent@happym.wa.com, tikal!camco!happym!kent, Happy Man Corp 206-282-9598

> description of numerous pcc bugs on 68020 system V machines . . .

We have had similar problems.  But motorola is just trying to get
the ridiculous code from AT&T to work.  (See what beaurocracy has done
to K&R's masterpeice? :-( )

Hint, use the old 6000 series from convergent technologies.  The
compiler on those generates absolutely terrible, but correct code.
(Constants are not even folded!) Get gcc going, then convert the gcc
binaries for the newer system V.

I have suggested that the Motorola people get gcc, but as the previous poster
said, don't hold your breath.
-- 
Stuart D. Gathman	<stuart@bms-at.uucp>
			<..!{vrdxhq|daitc}!bms-at!stuart>