chin@ankh.ftl.fl.us (Albert Chin) (06/18/90)
I have the following problem while using the desktop debugger under ORCA. I am debugging a program that has arrays (2) greater than 64K and have a "segment" statement in the middle of the program. While debugging the program, I return from one function that returns a value and do not get transferred back to the place where it was called. While I can 'cmpl' the program from the text environment, It constantly hangs, no doubt from the previous bug. I don't know what's going on. I'm goin to post a message to America OnLine this week to Mike Westerfield and hopefully he will have a response. I have taken out all NDA's, CDA's and have checked my memory which checks out ok. I would take out the memory card but then the program won't compile. I have also had problems in PRIZM with running out of memory. I have 3 megs and am compiling an application which is 133 blocks. Surely something must be wrong with prizm. It seems that when I first boot the computer things compile but every time after that I try to compile in prizm after that I get the dreaded "out of memory message". Anyone else encounter these bugs? thanks, albert ... mthvax!mamia!albert
acmfiu@serss0.fiu.edu (ACMFIU) (02/28/91)
for those of you using orca/c and prizm, the following is a bug.
consider the program:
void
foo (void)
{
int a;
a = 0;
while (TRUE)
{
int b;
b = 1;
break;
}
}
under prizm, you can view the variables of your program. prizm will allow
you to view the variable 'a'. however, it will not allow you to view the
variable 'b'. this is apparently a bug in orca/c's debug code generation.
it "should" be fixed in the next release of the compiler.
albertgt0t+@andrew.cmu.edu (Gregory Ross Thompson) (03/02/91)
While we're mentioning bugs in Orca/C, has anyone out there noticed any problems with declaring static variables in Orca? I'm working on porting something kinda big and useful from unix to the GS (don't ask, I won't tell you, because I may never finish), and I was having problems with the linker not being able to "find" ANY variable that was declared as static. Has anyone else noticed this? -Greg T. ------------------------------------------------------------------------ ^ Any resemblance between the above | ARPANet : gt0t+@andrew.cmu.edu ^ ^ views and those of my employer, my | ^ ^ terminal, or the view out my window | ^ ^ are purely coincidental. | Bitnet : R746GT0T@VB ^
gwyn@smoke.brl.mil (Doug Gwyn) (03/03/91)
In article <EbnpcPC00Vog88Zap4@andrew.cmu.edu> gt0t+@andrew.cmu.edu (Gregory Ross Thompson) writes: > While we're mentioning bugs in Orca/C, has anyone out there noticed >any problems with declaring static variables in Orca? The worst of those problems were fixed with ORCA/C release 1.1.
acmfiu@serss0.fiu.edu (ACMFIU) (03/07/91)
In article <EbnpcPC00Vog88Zap4@andrew.cmu.edu> gt0t+@andrew.cmu.edu (Gregory Ross Thompson) writes: > > While we're mentioning bugs in Orca/C, has anyone out there noticed >any problems with declaring static variables in Orca? I'm working on >porting something kinda big and useful from unix to the GS (don't ask, >I won't tell you, because I may never finish), and I was having >problems with the linker not being able to "find" ANY variable that >was declared as static. Has anyone else noticed this? > -Greg T. Greg, this is indeed a bug in orca/c. you will be happy to know that in the next release of orca/c (i don't know a date yet), that bug should be fixed. i have had severe problems with it and am just avoiding static variables now (i never throught i'd need them but now i do). anyway, mike will be posting a release not of when the new updated orca/c will be ready. i will then post that note to the net so keep abreast of what is happening here. it's safe to say the release should be out within one month. after all, since the manuals are being reprinted, mike decided to revisit the bugs in orca/c (the bugs were also mounting). i hope you're reported all your bugs :) albert
barry@rbdc (Barry Newberry) (04/06/91)
It appears that an old bug (feature?) has been left in Orca/C. Of course,
I never wrote Mike (W.) about it, because I thought someone else would
(my mistake). The compiler won't allow called functions to be type void.
The compiler blames the next line of code for the problem. From what I've
read, ANSI C allows functions to be type void, so I shouldn't have any
trouble with the following program. Changing type void functions to type
int takes care of the problems, but I like to use void for functions
which can't have errors or don't have to return values.
/****************strange C program**************/
void main (void)
{
thing ();
}
void thing (void)
{
}
/***************an attempt to compile***********/
ORCA/C 1.2
Compiling main
Compiling thing
7 {
^ duplicate symbol
/***************end of stuff********************/
I guess I'll have to play with the compiler to see how extern Assembly
functions are affected. Changing an Assembly function from void to int
means I'll have to return a value on the stack (what a waste :-)).
--
-------------------------------------------------------------------------
Remember, until there is a cure for Assembly Language Brain Fry,
there will always be the N.C. Home for Deranged Programmers.
-----------------------------------------------------------------------gwyn@smoke.brl.mil (Doug Gwyn) (04/09/91)
In article <1991Apr6.083344.26760@rbdc> barry@rbdc.UUCP (Barry Newberry) writes:
-It appears that an old bug (feature?) has been left in Orca/C. Of course,
-I never wrote Mike (W.) about it, because I thought someone else would
-(my mistake). The compiler won't allow called functions to be type void.
-The compiler blames the next line of code for the problem.
Oh, good grief! ORCA/C certainly does allow functions to have void
return type.
-void main (void)
-{
- thing ();
-}
-void thing (void)
-{
-}
-Compiling thing
- 7 {
- ^ duplicate symbol
The compiler is perfectly justified in complaining about your attempt
to define thing() as returning void when previously you gave it an
implicit declaration (by invoking it in the absence of a prior
declaration) as returning int.floyd@itsgw.rpi.edu (Patrick J Wetmore) (04/09/91)
In article <1991Apr6.083344.26760@rbdc> barry@rbdc.UUCP (Barry Newberry) writes: >It appears that an old bug (feature?) has been left in Orca/C. Of course, >I never wrote Mike (W.) about it, because I thought someone else would >(my mistake). The compiler won't allow called functions to be type void. >The compiler blames the next line of code for the problem. From what I've >read, ANSI C allows functions to be type void, so I shouldn't have any >trouble with the following program. Changing type void functions to type >int takes care of the problems, but I like to use void for functions >which can't have errors or don't have to return values. > >/****************strange C program**************/ It's ansi prototyping preventing you from making horrible mistakes. insert this line about here: ------ void thing(); ------ That will declare thing to be a function taking unknown parameters and returning void. >void main (void) >{ > thing (); As thing was not declared previously, the compiler assumed it was of type int. >} > >void thing (void) Because thing is being re-declared as void, it will give you a duplicate symbol error. >{ >} pat!
jh4o+@andrew.cmu.edu (Jeffrey T. Hutzelman) (04/09/91)
barry@rbdc (Barry Newberry) writes: > It appears that an old bug (feature?) has been left in Orca/C. Of course, > I never wrote Mike (W.) about it, because I thought someone else would > (my mistake). The compiler won't allow called functions to be type void. > The compiler blames the next line of code for the problem. From what I've > read, ANSI C allows functions to be type void, so I shouldn't have any > trouble with the following program. Changing type void functions to type > int takes care of the problems, but I like to use void for functions > which can't have errors or don't have to return values. > > /****************strange C program**************/ > void main (void) > { > thing (); > } > > void thing (void) > { > } This program IS erroneous. When you called thing() without a prior prototype, the compiler assumed it was type int. All C compilers I have ever seen do this. The proper code is below: /************* Corrected C Program *************/ void thing(); void main(void) { thing(); } void thing (void) { } /***********************************************/ That should compile correctly. > -- > ------------------------------------------------------------------------- > Remember, until there is a cure for Assembly Language Brain Fry, > there will always be the N.C. Home for Deranged Programmers. > ----------------------------------------------------------------------- -------------------- Jeffrey Hutzelman America Online: JeffreyH11 Internet: jh4o+@andrew.cmu.edu BITNET: JHUTZ@DRYCAS >> Apple // Forever!!! <<
acmfiu@serss0.fiu.edu (ACMFIU) (06/05/91)
with realloc() do
int
main (void)
{
char *foo;
foo = malloc (10);
strcpy (foo, "abc");
printf ("%s\n", foo);
foo = realloc (10 + 1);
printf ("%s\n", foo);
}
output:
abc
bc
now, if you change "realloc (10 + 1)" to "realloc (10 + 2)", things work
fine.
albertgwyn@smoke.brl.mil (Doug Gwyn) (06/06/91)
In article <3728@kluge.fiu.edu> acmfiu@serss0.fiu.edu (ACMFIU) writes: >int >main (void) >{ > char *foo; > foo = malloc (10); > strcpy (foo, "abc"); > printf ("%s\n", foo); > foo = realloc (10 + 1); > printf ("%s\n", foo); >} The above program is utterly wrong, and it is a wonder that it doesn't crash your system. (a) You must #include <stdlib.h> or else properly declare malloc() and realloc() before invoking them. (b) You must #include <stdio.h> or else properly declare printf() before invoking it. (c) You must #include <string.h> or else properly declare strcpy() before invoking it. (d) You must return an integer value from the main() function, or else terminate the program by invoking exit(). (e) realloc() takes two arguments.
acmfiu@serss0.fiu.edu (albert chin) (06/07/91)
In article <16345@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes: }In article <3728@kluge.fiu.edu> acmfiu@serss0.fiu.edu (ACMFIU) writes: }}int }}main (void) }}{ }} char *foo; }} foo = malloc (10); }} strcpy (foo, "abc"); }} printf ("%s\n", foo); }} foo = realloc (10 + 1); }} printf ("%s\n", foo); }}} } }The above program is utterly wrong, and it is a wonder that it doesn't }crash your system. } }(a) You must #include <stdlib.h> or else properly declare malloc() and }realloc() before invoking them. } }(b) You must #include <stdio.h> or else properly declare printf() before }invoking it. } }(c) You must #include <string.h> or else properly declare strcpy() before }invoking it. i assumed people would do this. }(d) You must return an integer value from the main() function, or else }terminate the program by invoking exit(). } }(e) realloc() takes two arguments. this was a typo on my part. the program will still not work when you change the realloc to 'foo = realloc (foo, 10 + 1);' albert
gwyn@smoke.brl.mil (Doug Gwyn) (06/08/91)
In article <3768@kluge.fiu.edu> acmfiu@serss0.fiu.edu (albert chin) writes: >this was a typo on my part. the program will still not work when you change >the realloc to 'foo = realloc (foo, 10 + 1);' I haven't yet tried your program (after fixing it up), so I don't know whether or not you have uncovered a bug in ORCA/C. However, note that you still need to get realloc() properly declared -- including its argument types -- before invoking it. The int expression is not compatible with the expected type for the second argument, and since the 65816 is a "little endian" architecture, this mismatch could go undetected in many cases.
acmfiu@serss0.fiu.edu (ACMFIU) (06/11/91)
In article <16363@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes: >In article <3768@kluge.fiu.edu> acmfiu@serss0.fiu.edu (albert chin) writes: >>this was a typo on my part. the program will still not work when you change >>the realloc to 'foo = realloc (foo, 10 + 1);' > >I haven't yet tried your program (after fixing it up), so I don't know >whether or not you have uncovered a bug in ORCA/C. >However, note that you still need to get realloc() properly declared -- >including its argument types -- before invoking it. The int expression >is not compatible with the expected type for the second argument, and >since the 65816 is a "little endian" architecture, this mismatch could >go undetected in many cases. i don't understand what you just said. do you mean that orca/c will have problems promoting '10 + 1' to size_t because it doesn't know about the prototype for realloc()? if this is so, then you're right. but all you need to do is "#include <stdlib.h>" for orca/c to automatically promote the '10 + 1' to size_t. incidentally, i even tried '(unsigned long)(10 + 1)' as the parameter so if orca had problems this should have fixed it. i don't think it has problems promoting arguments though. in coff i prototype everything and i know i pass values like 'char' that are promoted to 'unsigned long' and they work just fine. next time i'll post the *entire* program so we don't get into this confusion again. i just hope i didn't make the same mistake on AOL when i listed the bug. albert