Xref: utzoo comp.sources.d:3712 comp.lang.c:19094 comp.sys.ibm.pc:29628
Path: utzoo!attcan!uunet!husc6!rutgers!mcnc!duke!romeo!gm
From: gm@romeo.cs.duke.edu (Greg McGary)
Newsgroups: comp.sources.d,comp.lang.c,comp.sys.ibm.pc
Subject: Re: Flex compilation with TC
Keywords: Flex, MS-DOS, TC
Message-ID: <14614@duke.cs.duke.edu>
Date: 2 Jun 89 02:34:30 GMT
References: <394@tuewsd.UUCP>
Sender: news@duke.cs.duke.edu
Reply-To: gm@romeo.UUCP (Greg McGary)
Organization: Duke University CS Dept.; Durham, NC
Lines: 25

In article <394@tuewsd.UUCP> wsinpp@tuewsd.UUCP (Peter Peters) writes:
>I tried to compile Flex (the lex replacement) on an IBM-PC
>using Turbo-C 1.0. The compilation works just fine (a few
>warnings) but the resultant executable seems to be corrupt.
>Execution of flex produces an empty lex-yy.tab (lex.yy.tab)
>file and simply stops the machine. Using ^C gives the message
>that something is wrong with memory allocation and that
>command.com cannot be loaded, so the machine is dead.
>Anyone out there who can enlighten me ?
>If this is not the correct newsgroup for this kind of message
>I'm sorry..

If you compile flex with `-N' enabling stack-overflow detection, you
will discover that the stack is overflowing.  No matter how big you
make _stklen, this will persist.  The problem is that the time(3) library
function called from gettime() itself calls an internal function called
gettime(), so you get stuck in an infinite double-recursion.  The workaround
is to rename flex's gettime() to get_time() or some such.

Also, be sure to compile with the large-model...

-- Greg McGary
-- 10310 Main Street #354, Fairfax, Virginia 22030    voice: (703) 266-7249
-- {decvax,hplabs,seismo,mcnc}!duke!gm                 data: (703) 266-7258
--                                  gm@cs.duke.edu