[comp.unix.microport] Problems with C compiler

gbm@gbmatl.UUCP (gary mckenney) (09/28/88)

I've long since given up on my 286 microport for all the problems I encountered
with it.  (A never ending list).  But the main decision for giving it up dealt
with some code I was attempting to port over to it.  This code I have
successfully ported to XENIX 286,386, UNIX SYSTEM V on 386 (not microport's).

The problem occured in a complicated switch() statement.  When executing the
code every case: in the switch() I was able to execute but when I attempted
the default: then the jump that occured took me out where no man has gone
before.

In fact this occured in two switch statements.  I finally determined that
this was caused by the size within the switch statement alone.  I called
microport but they had no clue and requested a copy of the code.  I didn't
want to bother sending it to them.  I tried coming up with a simplified
version of the switch but I was unable to reproduce it.  And I know what
some of you are thinking that the problem had to be with the code.  Trust
me it wasn't.

Has anyone heard of similiar problems ?

What is the credibility of the 386 Microport UNIX compared to the 286?

gbm

bowles@lll-crg.llnl.gov (Jeff Bowles) (09/29/88)

In article <1199@gbmatl.UUCP> gbm@gbmatl.UUCP (gary mckenney) writes:
>The problem occured in a complicated switch() statement...
>
>I finally determined that
>this was caused by the size within the switch statement alone.  I called
>microport but they had no clue and requested a copy of the code.  I didn't
>want to bother sending it to them.  I tried coming up with a simplified
>version of the switch but I was unable to reproduce it....

How can you expect someone ELSE to reproduce a problem that is so
complex that you couldn't reduce it to a simpler example? Yet you
"didn't want to bother sending it [the original code] to them"?

Gees, a customer support person is only as good as the data you give
him (her), and it sounds like you fed them little information on a
complex problem.

End result: the bug that aggravated you will live on, to bug someone
else.  Whose fault is that?

	Jeff Bowles

det@hawkmoon.MN.ORG (Derek E. Terveer) (10/02/88)

In article <1199@gbmatl.UUCP>, gbm@gbmatl.UUCP (gary mckenney) writes:
> [..] I finally determined that
> this was caused by the size within the switch statement alone.
> 
> Has anyone heard of similiar problems ?

I have seen similar problems in other compilers from other vendors (like even
on a cdc mainframe!) when the number and/or size of the code within the
switch/case statement exceeds some power of 2, for example, 32K or 64K or
something like that.  I think it had to do with generating local jumps within
the switch...  Also, if the absolute *range* of your cases is very large as
well, that can sometimes cause problems.

In any event, if it *is* because your code is too big, there should be a
relatively easy way to side step the issue, like use function calls, etc.  Of
course, its easy for me to say -- i'm not coding your application!

derek
-- 
Derek Terveer		det@hawkmoon.MN.ORG
			w(612)681-6986	h(612)688-0667

"A proper king is crowned" -- Thomas B. Costain