murphys@cod.UUCP (Steven P. Murphy) (06/10/87)
I am having troubles with C, MSC V3.0 to be exact. I have written a program on a pc to do some matrix operations and I had been using LINT on a main frame to help debug it. The problem is it compiles on the main frame with % cc filename -lm and runs, but on the pc I use: > msc /AL /FPi filename > link /STACK:65000 filename and all I get is stack overflow. Any help with what I'm doing wrong would be greatly appreciated. Thank in advance. Murph,
bright@dataio.Data-IO.COM (Walter Bright) (06/10/87)
In article <720@cod.UUCP> murphys@cod.UUCP (Steven P. Murphy) writes:
-I am having troubles with C, MSC V3.0 to be exact.
-I have written a program on a pc to do some matrix operations
-and I had been using LINT on a main frame to help debug it.
-The problem is it compiles on the main frame with % cc filename -lm and runs,
-but on the pc I use:
- - msc /AL /FPi filename
- - link /STACK:65000 filename
-and all I get is stack overflow. Any help with what I'm doing wrong
-would be greatly appreciated.
First of all, without seeing your source code I can only guess. My
suspicion would be that you are declaring large arrays (matrices) using
the automatic (on the stack) storage class. It's easy to get excessively
large automatic arrays, even a
double matrix[10][10];
allocates 10*10*8 = 8000 bytes on the stack. I have run into similar
problems many times when porting code from a mainframe.
The solution is to use static storage class, or malloc().billc@blia.UUCP (06/12/87)
In article <720@cod.UUCP>, murphys@cod.UUCP (Steven P. Murphy) writes: > I am having troubles with C, MSC V3.0 to be exact. > > link /STACK:65000 filename > and all I get is stack overflow. Any help [ ... ] MS doesn't like big stacks. We tried /STACK:32768 and it overflowed. Try some smaller number and experiment until you get the largest number that works. Changing the amount of static data will probably change this magic number. -- W.H.Coffin. billc@blia.BLI.COM Or, if you really like source routing, try ucbvax!{mtxinu|ucsfcgl}!blia!billc >> the usual disclaimer about my employer and my wretched opinions. << >> the usual witticisms that swell netnews to ridiculous proportions. <<
peter@sugar.UUCP (Peter DaSilva) (06/18/87)
In article <YUo0hEy00VsGy9c0=e@andrew.cmu.edu>, mc35+@andrew.cmu.edu (Mark Chance) writes: > > ... but on the pc I use: ^^ > > > > > msc /AL /FPi filename > > > link /STACK:65000 filename > > > > and all I get is stack overflow. Why are there postings about IBM-PC specific problems in a generic 'C' group? Isn't there a comp.sys.ibm-pc group? Not all of us have systems limited by intel's militant segmentism, and some of us had hoped to avoid it by 'ug'-ing ibm and intel specific groups.
murphys@cod.UUCP (Steven P. Murphy) (06/24/87)
In article <199@sugar.UUCP>, peter@sugar.UUCP (Peter DaSilva) writes: > In article <YUo0hEy00VsGy9c0=e@andrew.cmu.edu>, mc35+@andrew.cmu.edu (Mark Chance) writes: > > > ... but on the pc I use: > ^^ > > > > > > > msc /AL /FPi filename > > > > link /STACK:65000 filename > > > > > > and all I get is stack overflow. > > Why are there postings about IBM-PC specific problems in a generic 'C' > group? Isn't there a comp.sys.ibm-pc group? Not all of us have systems > limited by intel's militant segmentism, and some of us had hoped to avoid > it by 'ug'-ing ibm and intel specific groups. The original question was one of portability. It ask why a program that would compile fine in a UNXI environment would bomb in a micro envrionment even when general allowances were made for compiler differences.