CompuServe Thread

The following examples illustrate some of the bugs I've encountered with 5.0a to date. Bug 1: 5.0a treats 0.0 as a char in the presence of float prototypes. Example: void foo( float null ) { } main(void) { foo( 0.0 ) ; } Aztec C Version 5.0a Jan 9 1990 7:57:19 Copyright 1989 by Manx Software Systems, Inc. clr.s -(sp) ^ File TMPA341.TMP; Line 16 # Opcode extension size did not match. 1 errors Bug 2: Prototypes are not generated correctly for functions taking array, or pointer to array arguments. Example: void foo1( char (*array)[3][2] ) { } void foo2(array) char (*array)[3][2] ; { } The above program, test.c, when compiled with -qp produces: void foo1(char array[2][3]*); void foo2(char array[2][3]*); Bug 3 (example superfluous): -wq logs only the first 25 (approximately) errors to AztecC.err. Additional errors are not logged, even when -ww is used. Tracking down these bugs takes time. Reporting the bugs in a general sense is much easier. In this spirit I've encountered the following additional bug. Bug 4 (sans example): _stkchk (via the -bd option) will occasionally corrupt the instruction immediately following its invocation (i.e. immediately following jsr __stkchk). Bug 5 (suspected, but not confirmed): sizeof(int) may not be working correctly. I *suspect* that sizeof(int) does not know whether 16 bit or 32 bit ints are being used, although I *have not* confirmed this. I rewrote the code using sizeof() and my problem disappeared. Forgive me if I seem blunt in my criticism of 5.0a. I realize that much has changed since 3.6 and that errors can be expected. If Manx supports 5.0a with courtesy, and corrects bugs promptly – if it offers the level of customer support which has been so very lacking in the past – perhaps I'll get over my grumpiness :-).

I have not found any identifyable bugs yet. I had the compiler go into an endless loop on me last night while compiling uEmacs 3.10, but when I restarted the make, the same file compiled with no problems. I had been changing header files to make the compiler happy and the changes did not affect thefile which choked the compiler. In fact with all the changes in the header for other files, this file must have been recompiled five or six times and only hung the compiler once… strange. Error # 167 (expression too complex – simplify and recompile) is not documented anywhere I can find and was emitted by the compiler when it tried to evaluate the following expresstion: char name[SIZE]; struct foo { char n_name[SIZE]; … etc… }; int *iP; struct foo *fP; name[*iP] = fP->n_name[*iP]; this blows up While I have in the past seen similar errors (CP/M comiler ~8 years ago?, expression with several more pointer dereferences), I've never seen it on such a simple expression. The 3.6 compiler had no problems with exressions much more complex than this. While declaring an extra temp variable to hold the index works, I shouldn't have to do this! <UP ON SOAPBOX> This is yet another gripe to another software developer about …Obnoxious compiler version and copyright notices… Why is it that everyone insists on throwing this information all over the screen EVERY TIME THE PROGRAM RUNS??? I know what version of what compiler I'm running. I know who has the copyrights. Why do I have to sift through all this garbage to see what happened when I ran the program? A simple command line switch would suffice if I forgot! <DOWN OFF SOAPBOX>

Who me? A programming error. Nah, couldn't be :-). John, I know you're a big Manx advocate, citing product stability as its strong point. 5.0a has shaken my confidence. Examples will be posted to Mike in this forum. Stay tuned …