bryan@iconsys.UUCP (Bryan Cardoza) (03/22/89)
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
The relevant m68k assembly code is:
mov.l &_p,(%sp) # This is correct
mov.l &L%15,-(%sp)
jsr _printf
add.l &4,%sp
tst.l _p # OOPS! This should be "&_p".
Any pointers?
--
Bryan Cardoza uunet!iconsys!bryan
Software Engineer
SANYO/ICON Telephone: (801) 225-6888
Orem, Utah FAX: (801) 226-0651dbsuther@PacBell.COM (Daniel B. Suthers) (04/01/89)
>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;
chris@mimsy.UUCP (Chris Torek) (04/02/89)
-> 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!chrisguy@auspex.auspex.com (Guy Harris) (04/02/89)
>> 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.
kent@happym.wa.com (Kent Forschmiedt) (04/03/89)
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
stuart@bms-at.UUCP (Stuart Gathman) (04/06/89)
> 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>geoff@desint.UUCP (Geoff Kuenning) (04/10/89)
In article <765@happym.wa.com> kent@happym.UUCP (0000-Kent Forschmiedt) writes: > p && free(p); Note that this is an illegal statement on most modern Unixes, because free() is (or should be) declared with a void return value. (Of course, if free() is replaced by any routine that returns a value, the compiler should be able to handle it, regardless of the fact that it is horrible coding style.) -- Geoff Kuenning geoff@ITcorp.com uunet!desint!geoff
kent@happym.wa.com (Kent Forschmiedt) (04/12/89)
>In article <765@happym.wa.com> I mention that my compiler mishandles >> p && free(p); In article <21@desint.UUCP> geoff@desint.UUCP (Geoff Kuenning) writes: >Note that this is an illegal statement on most modern Unixes, because free() >is (or should be) declared with a void return value. (Of course, if free() >is replaced by any routine that returns a value, the compiler should be >able to handle it, regardless of the fact that it is horrible coding style.) Perhaps it is horrible coding style, and perhaps it is not, depending on who you ask. I probably use a lot of methods that you would call horrible. If you ask Richard Stallman, I hope he says it isn't, because GNU is rife with it. In any case, the language that we call C supports that style, while the program that Motorola calls a C compiler does not, and so does not compile unmodified GNU sources. -- kent@happym.wa.com, tikal!camco!happym!kent, Happy Man Corp 206-282-9598