"jacob navia" <jacob@[EMAIL PROTECTED]
> wrote in message
news:4661ea93$0$27383$ba4acef3@[EMAIL PROTECTED]
> Consider this program:
> int fn(int a)
> {
>
> if (a == 6 || a == 7 || a == 4 || a == 67 || a == 78 &&
> a == 6 || a == 7 || a == 4 || a == 67 || a == 78 &&
> a == 6 || a == 7 || a == 4 || a == 67 || a == 78 &&
> a == 6 || a == 7 || a == 4 || a == 67 || a == 78 &&
>
> (4955 lines exactly the same as above elided)
>
> a == 6 || a == 7 || a == 4 || a == 67 || a == 78 &&
> a == 6 || a == 7 || a == 4 || a == 67 || a == 78 )
> return 1;
> return 0;
> }
>
> This program makes the lcc compiler crash with stack overflow.
Are you able to detect the overflow prior to the overflow?
> Fixing this would have to change drastically the design of the
> compiler. In the other hand leaving this as is would leave a
> compiler that can crash in some cir***stances.
>
Increasing the stack size would require drastic redesign?
> What can I do here?
>
If you can detect overflow and underflow of the stack prior occurrences of
them, you might be able to fix the problem. Assuming the stack is large,
much of the data it contains won't be used for a while. I.e., only the
top
elements of the stack are acting like a stack, the rest are just being
stored until the program gets back around to using them. So, you could
create another place to store them: an overflow buffer. Allocate enough
memory for another stack. Copy the stack contents to the overflow buffer.
Reset your stack pointers (stack is now empty). Go back to using the
stack.
When the stack is about to underflow, copy the overflow buffer back.
Reset
your stack pointers (stack is now full). Go back to using the stack. If
the stack is pu****ng and poping alot right around the overflow condition,
you'll end up thra****ng the stack. You might choose to copy 3/4 of the
stack in that case so that some elements are left to prevent the
thra****ng.
> Is this legal C?
>
Does that really matter?
(BTW, DJGPP and OW fail too...)
Rod Pemberton
|
