chasm@killer.UUCP (Charles Marslett) (05/12/88)
Keywords: flex for MSDOS
Newsgroups: comp.sources.d,comp.lang.c
Well I just finished making flex (Fast lex from Vern Paxson) work (more
or less) under PCDOS 3.3. The reason for this posting is to raise
another 'C' question and to ask if others have had luck running flex
on non-unices (This posting is a plagarism of John Campbell's discussing
VMS, in case it looks familiar!).
My 'C' question is
Flex has two register variables, yy_curst andyy_sym declared in a nested
block beginning with the label "get_next_token". That block is reentered
at the label "find_rule" when an action is "REJECT"ed and the code appears
to presume the variable yy_curst is unchanged. Does the ANSI standard (or
K&R for that matter) have anything to say about exiting a context and
reentering it saving (or not saving) the state of local variables? Might
the fact that this code seems to work almost everywhere imply that Unix
and VMS (AT&T derived?) C compilers allocate local variables on the
entry to the function, rather than entry to the block? Enquiring minds
want to know (-; .
Commentary w.r.t. flex on MSDOS systems:
Two of the same basic changes were made to enable flex work on MSDOS as
were made for VMS: the long symbols in flexdef.h and the names of the
files needed to be changed (differently I'm sure). Also, I had to define
SV and allocate a larger stack than Microsoft presumes (2048 bytes!!) --
the largest I could get the linker to take was 40960 bytes (0xA000). I
also might mention that I am running with the Microsoft 5.1 C compiler.
>> MUCH THANKS TO VERN PAXSON, KEVIN GONG, VAN JACOBSON, ET.AL.!!!!!!
and to John Campbell for organizing my thoughts!
--
Charles Marslett
chasm@killer.UUCP
henry@utzoo.uucp (Henry Spencer) (05/15/88)
> ... Does the ANSI standard (or > K&R for that matter) have anything to say about exiting a context and > reentering it saving (or not saving) the state of local variables? All definitions of C that I'm aware of make it quite clear that the values of uninitialized local variables are unknown when the block containing them is entered, *regardless* of whether the block was executed before and gave them a value then. Old values go away when the block is exited. > Might > the fact that this code seems to work almost everywhere imply that Unix > and VMS (AT&T derived?) C compilers allocate local variables on the > entry to the function, rather than entry to the block?... Correct in general. But it's not something one should depend on, of course. Even if allocation is at function-entry time, clever compilers may well re-use the space for something else after the block is exited. -- NASA is to spaceflight as | Henry Spencer @ U of Toronto Zoology the Post Office is to mail. | {ihnp4,decvax,uunet!mnetor}!utzoo!henry
daveb@geac.UUCP (David Collier-Brown) (05/16/88)
In article <1988May15.002127.413@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >All definitions of C that I'm aware of make it quite clear that the values >of uninitialized local variables are unknown when the block containing >them is entered, *regardless* of whether the block was executed before and >gave them a value then. Old values go away when the block is exited. >... >Even if allocation is at function-entry time, clever compilers may well >re-use the space for something else after the block is exited. Specifically, I once saw a compiler re-use the recently-exited context for the stack frame of a subroutine call, and notice that a copy of a needed parameter value was laying around just where it would be needed in the call. So it didn't move it. (I've heard of register histories, but they must have been keeping top-of-stack histories to do that!) --dave