[comp.unix.xenix.sco] Xenix cc bugs

cjm@iris.mincom.oz.au (Chris Moran) (11/21/90)

We have discovered the following bugs in our SCO Xenix cc :

1)  This code elicits
        "fatal error C1026: parser stack overflow, please simplify your
        program"

    from cc :
        while (1) {
            while (1) {
                ...             /*  nested to a depth of 12  */
                ;
            }
        }

    If while() is substituted with for(), the permitted nesting depth drops
    to 7.

    Though hand-crafted C code rarely reaches these depths of iteration in a
    single function, an automatic code generator such as a language translator
    can burst this limit rather easily.

    SCO knows about this problem, but replies that this "feature" does not
    warrant the allocation of development resources.

2)  Compiling this program with "cc -M3e -g" generates an executable whose size
    is _260K_.

        static int funct (void);

        main (argc, argv)
            int argc;
            char *argv[];
        {
            funct ();
        }

        static int
        funct (void)
        {
            ;
        }

    Removing the void specifier and hence reverting to old-style function
    declarations, or removing static, or compiling without symbolic info
    (the -g flag), creates a binary more suiting the code (8 K).

    SCO have yet to hear about this one.


We are running with SCO Xenix 386 SysV, Rel. 2.3.2, Development system 2.3.1,
with SLS lng244 installed.

Anyone with similar stories?


Chris Moran
cjm@mincom.oz.au

davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (11/23/90)

In article <720@iris.mincom.oz.au> cjm@iris.mincom.oz.au (Chris Moran) writes:

| We are running with SCO Xenix 386 SysV, Rel. 2.3.2, Development system 2.3.1,
| with SLS lng244 installed.

  I don't see a lot of this anymore with the recent versions, but there
was a lot of it, and you can (as you showed) still stumble of it. My
favorite was one program which broke the parser because of nesting, just
like yours, but the break fell on a line saying:

	if (ALMODE) {

where the config.h #defined ALMODE to 1. I called SCO and the 1st level
person I talked to, on being told the ALMODE was one, suggested I could
"siplify the program by setting ALMODE to zero."

  Later one of their top people got on the line with me and gave me the
*real* answer: "that's a known bug."

  I figure that for every hour I spend on a bug I save a day by being
able to cross compile to Xenix/286 and DOS, so I use the compiler, and
have little trouble with the current versions.
-- 
bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen)
    sysop *IX BBS and Public Access UNIX
    moderator of comp.binaries.ibm.pc and 80386 mailing list
"Stupidity, like virtue, is its own reward" -me