[comp.lang.c] Turbo C Problem?

daver@hcx2.SSD.HARRIS.COM (02/26/88)

The following dumb, little program is compiled with Turbo-C 1.0, running under
MS-DOS 3.2.  Shortly after starting up, the C compiler goes berserk.  The
screen flashes in reverse video and the operating system reboots itself.
In a larger example, the auto-reboot does not take place, but the C compiler
hangs up, the recommended "control-break to quit" has no effect, and I have
to reboot the system anyway.  What is going on?  Is this a C compiler
problem?  Would there be any difference in version 1.5?

#define R 41
#define C 480
main()
{
   struct
   {
      unsigned a:1;
   } b[R][C];

   int i, j;
     for (i=0; i<R; ++i)
      for (j=0; j<C; ++j)
      {
         b[i][j].a = 0;
      }
}

swarbric@tramp.Colorado.EDU (Frank Swarbrick) (02/27/88)

To daver@hcx2.SSD.HARRIS.COM:

  I compiled your little program that you said basically blew up in Turbo C 1.0
using 1.5 and it doesn't do my machine any harm...

Frank Swarbrick (and his cat)
swarbric@tramp.UUCP               swarbric@tramp.Colorado.EDU
...!{hao|nbires}!boulder!tramp!swarbric
 "People think I'm insane because I am frowning all the time"

pjh@mccc.UUCP (Peter J. Holsberg) (02/28/88)

In article <44100006@hcx2> daver@hcx2.SSD.HARRIS.COM writes:
|
|
|The following dumb, little program is compiled with Turbo-C 1.0, running under
|MS-DOS 3.2.  Shortly after starting up, the C compiler goes berserk.  The
|screen flashes in reverse video and the operating system reboots itself.
|In a larger example, the auto-reboot does not take place, but the C compiler
|hangs up, the recommended "control-break to quit" has no effect, and I have
|to reboot the system anyway.  What is going on?  Is this a C compiler
|problem?  Would there be any difference in version 1.5?
|
|#define R 41
|#define C 480
|main()
|{
|   struct
|   {
|      unsigned a:1;
|   } b[R][C];
|
|   int i, j;
|     for (i=0; i<R; ++i)
|      for (j=0; j<C; ++j)
|      {
|         b[i][j].a = 0;
|      }
|}


In version 1.5, your program compiles without error and, on execution,
does nothing.

-- 
Peter Holsberg                  UUCP: {rutgers!}princeton!mccc!pjh
Technology Division             CompuServe: 70240,334
Mercer College                  GEnie: PJHOLSBERG
Trenton, NJ 08690               Voice: 1-609-586-4800

leo@philmds.UUCP (Leo de Wit) (03/01/88)

It could be that your program has not allocated enough stack space.
I myself had a similar problem using a Lattice-C compiler for the Atari-ST.
The compiler reserves some default stack space for the program to run in
(usually about 2K). You can alter it by initiating the global variable _stack,
	e.g.:

int _stack = WHAT_I_NEED;

Also the actual memory requirements for the program can be set by assigning to
an other global, _mneed:

int _mneed = ALL_I_CAN_GET; /* or something like that */

The default for the Atari is that all but 4K of the memory is taken by the
program. So if you're planning to write a shell or a make utility or whatever
program that does have to leave some memory, use this assignment.

The bomb that goes off in your program could be that by assigning to the 
structure elements (which are on the stack) you end up by writing on addresses
that have not been reserved for the stack. So the solution seems to me:
	either use something similar like the above (check your compiler!) or
don't push such large data elements on the stack (small machines, but also even
large ones generally don't like that); use static allocation for that.

                            L.J.M. de Wit