acmfiu@serss0.fiu.edu (ACMFIU) (11/26/90)
as soon as i got orca/c 1.0 and found all the bugs, i was really disappointed. then i got orca/c 1.1 And found more bugs, again i was disapppointed. now i know why orca/c has so many bugs. it was written primarily in pascal with some assembly for speed.
acmfiu@serss0.fiu.edu (ACMFIU) (01/31/91)
several people have posted requests for anyone finding bugs in orca/c to
let fellow netters know. well, this is the first of such posts. i hope i
am not the only one doing this as i'd also be interested in hearing from
others (BTW, mike will be addressing the bugs in orca/c very soon so send
him any bug reports you have now to make very sure he addresses them soon).
1. #pragma debug 25
i have a 1400+ line program that this fails in. i mainly use it to
check for problems with the stack (i.e my function wants a long and
i pass an int). orca has stack correcting code for this but it is
much nicer for you to have a clean program. now, the error happens
when you call a function that accepts no parameters (i.e. void). i
can't figure out why this has happened. several others on AOL have
likewise figured this out. on small programs (who knows how many
lines here) this #pragma seems to work fine.
2. #pragma optimize -1
this, in my opinion, should never be used. i suggest only using
'#pragma optimize 3'. the '-1' will turn off stack repair code.
therefore, if you pass an int value to a routine that accepts a long
your program will definitely crash. too bad '#pragma debug 25'
doesn't always work or we could find these things out.
3. prototype all functions
this is a real stupid bug. i had two dumb c routines to demonstrate
this bug that i sent to mike. i did not prototype these two functions
and, i got an error in the beginning of the second function (at the
'{') that said something like 'bad label'. anyway, when i prototyped
the function everything worked fine. as a general rule, i know
prototype everything (which should be done anyway). i also had a
22,000+ line program (thank goodness for emacs and memory) and i
decided to see if orca could handle it. well, i got numerous errors
with '{' and also 'local variable space exceeded' which was also
a bug because my local variables would never exceed stack space.
4. bad code generation
this has only happened in one instance but it took several days to
find (thank you GSBug) and 5 minutes to fix. i had a C program that,
when it would call another function, would never return from that
function, even if the function was "void foo(void) { }". this was
particulary bothersome. anyway, i traced through the program with
GSBug and found out that orca/c had generated bad code and was
destroying the contents of the stack (and thus the address to return
to after foo() was executed was destroyed. the simple patch to this
was an inline asm routine that saved the contents of the stack and
direct page, called the function (in the asm routine via jsl), then
restored the stack and direct page. it was vital to jsl to the
function, rather than using "foo ()". i have not heard other stories
of this happening to anyone and i know my code didn't corrupt the
stack (as stated before "void foo(void) { }" didn't work so it wasn't
my code).
5. NULL == 0
in many old-style (read k&r) code, you see NULL and 0 intermixed.
well, orca/c balks at this. i had one program i was converting over
from UNIX which had 0 and NULL intermixed. it crashes. i replaced all
0's with NULL's and it worked fine. personally, i don't think anyone
should ever use 0.
6. inline asm
the inline "asm" feature is nice. yet it is also buggy. for some
reason it doesn't seem to like 'rtl'. i have to use 'dcb 0x6b' in
it's place. now 'rtl' sometimes works. it worked once for me in
a 1400+ line program but then when i inserted it into a 3100+ line
program (without any changes to the asm code), orca/c balked at
me about it. nothing major but be careful.
7. static variables
orca/c v1.0 had problems with this. v1.1 supposedly fixed this but
this is not true. in small programs i seems to work. but in programs
over 1000 lines it doesn't seem to work. the problem is that the
static variables get saved in the ~GLOBALS data segment. however,
with these 1000+ line programs the compiler fails to save the variable
name in the ~GLOBALS segment and therefore the linker gives you
unresolved variable references when you link. this is a real pain.
several others on AOL have encountered this.
8. 'const' type qualifier
orca/c has problems with this. i encountered this a few months back
and kinda forget what error i get but Doug McIntyre has also discovered
problems with this. rule of thumb: don't use it, although some of
the library .h files have 'const' in it.
9. array indexing
the following code will access the last element in a char array:
foo[strlen (foo) - 1] = '/'
*(foo + strlen (foo) - 1) = '/'
these two, however, fail to work, for me anyway, in large programs,
again 1400+ lines. to fix the bug, i had to declare a dummy local
variable of type 'unsigned long' (even 'int' would do) and then say:
foo[strlen (foo) - num] = '/'
*(foo + strlen (foo) - num) = '/'
this is a particularly troublesome bug because it might just as well
apply to indexing other elements of the array (although i know of no
other even though i tried). also, note that this works:
foo[strlen (foo) - 2] = '/'
this accesses the second to last element. now you explain this to me?
10. a = (1 == 1 ? 1 : 2)
i think this is called the trinary operator but i forget (anyway, you
can get the picture by my example). now, i was porting GNUregexp
and orca gave type mismatch errors on a trinary operator in the code.
so i matched all the types and sure enough everything was OK. however,
i have had no problems with this. neverthless, good 'ol if..then
solved the problem in the regexp program. just beware.
11. out of memory
i have a program that's about 3000+ lines (i think) and when i
compile it i get "out of memory" errors which is ridiculous because
i have 4 megs of memory. mike has duplicated this error but has been
unable to solve the problem. i had 2 megs once i attempted to port
p2c. i had the same problem. then when i got 4 megs the problem went
away. obviously this is due to memory mismanagement in orca/c. beware.
well, that's all for now. for those adding to the bugs, please don't bash
byteworks (i can't believe i said that). at least mike *does* fix the bugs
and i think we will like v1.2 (or whatever is next) much better (and if not
i will be the first to bash mikey).
alberttoddpw@nntp-server.caltech.edu (Todd P. Whitesel) (01/31/91)
acmfiu@serss0.fiu.edu (ACMFIU) writes: >1. #pragma debug 25 >2. #pragma optimize -1 >3. prototype all functions #pragma lint -1 will tell you if you're passing the wrong size parameters, if you prototype your functions (a good idea in any case). >5. NULL == 0 Perhaps this fails because NULL is a long equaling zero and 0 is an int equaling zero. I've noticed that Orca/C fails to do implicit type-conversion in certain cases, and adding L's or (long)'s always fixes the problem. >6. inline asm Always works like a charm for me, with one exception: the mini-assembler always puts 16 bit immediates in the generated code -- it appears to only change the immediate operand size after the close bracket of the asm{} and then it uses 8 bit immediates for the rest of the source file! Since I was forgetting to restore the register sizes anyway, fixing my bug circumvented Orca's. >7. static variables I'm surprised you can put up with 1000 line source files -- I start splitting mine up if they're going to be more than a couple hundred lines. Orca's support for multiple object files is excellent and it's been there since the original Orca/M for the ][+. >9. array indexing > foo[strlen (foo) - 2] = '/' try 2L and see what happens. >10. a = (1 == 1 ? 1 : 2) I tried the above expression with nothing else around it and it compiles fine. Try sprinkling parenthesis on the off chance that the order of operators is off; if a is a long then L's are probably a good idea also. >11. out of memory Haven't had that problem yet, most likely because none of my source files is longer than 500 lines. I highly recommend organizing your project in small chunks of related subroutines, it works great -- example: ga.c (top level code) lhg.c (Lord High Giffer GIF file parser) rblk.c (GIF raster decompression -- no longer used) rblk.asm (GIF raster decompression, call w/ same prototype as rblk.c) di.c (color crunching and picture display) gsio.c (GS/OS operations; Nice C functions to hide the pBlock stuff) None are over 350 lines. Since I am usually doing intensive work on only one of these files at a time, I save at lot of time in recompiles. I don't like using the specific subroutine compile. Todd Whitesel toddpw @ tybalt.caltech.edu P.S. LHG is going to undergo a major rewrite -- whether that happens before or after I release the demo version is still unknown at this point.