|
From: | bhowse |
Subject: | Fw: Bison-1.875 Bug Report |
Date: | Sat, 24 Apr 2004 23:33:44 -0600 |
Dear Bison Admin,
I think I have discovered a bug in the latest release of Bison-1.875 but I don't understand the execution flow well enough to officially declare this as a bug or a potential problem depending on config.h definitions. I have unarchived the source code from bison-1.875.tar.gz and altered the config.h file to try and compile under msdos (bad word, I know). The only really difficult problem was subpipe.c in subdirectory Lib and the Unix Fork code to invoke M4 in the later stages of execution. I have resolved the subtask launching of M4.exe to process the macros using equivalent code from the Microsoft operating system C runtime environment. I have provided that code for you if you are interested. As for the Bug, here are the details from my perspective: scan-gram.c as produced by flex, on or about line 1893 has a reference to a portion of scan-gram.l (#line 614 "scan-gram.l") /*---------------------------------------------------------------. | Scanning the epilogue (everything after the second "%%", which | | has already been eaten). | `---------------------------------------------------------------*/ case YY_STATE_EOF(SC_EPILOGUE): #line 614 "scan-gram.l" { STRING_FINISH; loc->start = code_start; val->chars = last_string; BEGIN INITIAL; return EPILOGUE; } YY_BREAK Config.h has an option for compiler "lint" as follows: /* Define to 1 if the compiler is checking for lint. */ #define lint 1 The "lint" define is related to the scan-gram.c file and conditionally initializes some variables to prevent the compiler from warning about the possibility of using variables before they are initialized. Specifically, the variable "code_start" as used in epilogue during the final pass is undefined when "lint" is not used and then copied into "loc->start" which later causes the program to crash. I don't know if the initialized value from declaring "lint" is the correct value to be used in the variable or if the value having been initialized by "lint" is incorrect anyway, according to the flow of execution. Either way, there seems to be an error of some sort that "lint" may or may not correct. The initial value of "code_start" supplied by "lint" in the following code segment from scan-gram.c
is good enough
to prevent the program from crashing but I
am not sure if
this value really is "good enough" for
proper execution.
YY_DECL { register yy_state_type yy_current_state; register char *yy_cp, *yy_bp; register int yy_act; #line 127 "scan-gram.l" /* Nesting level of the current code in braces. */ int braces_level IF_LINT (= 0); /* Parent context state, when applicable. */ int context_state IF_LINT (= 0); /* Token type to return, when applicable. */ int token_type IF_LINT (= 0); /* Location of most recent identifier, when applicable. */ location id_loc IF_LINT (= *loc); /* Where containing code started, when applicable. */ --> boundary code_start IF_LINT (= loc->start); /* Where containing comment or string or character literal started, when
applicable. */
boundary token_start IF_LINT (= loc->start); I have checked all the variables
initialized by "lint"
and the only one that appears to be
incorrect during
runtime is the "code_start" variable.
Each pass through
the YY_DECL() the variables are either
undefined (no lint)
or they are initilized by the calling
process. All accesses
to "code_start" prior to epilogue seem to
be subsequently
initialized even though the YY_DECL()
function entry is
uninitialized. At the
failing point during epilogue, the
variable "code_start" is still
uninitialized when it is
required. Maybe, some compilers have
residue on the
stack that is acceptible for the
variable to prevent
program crashing.
Quite possibly, this problem is related to
scan-gram.l
and Flex rather then Bison but since Bison
is using this
file it may also be an
inherited problem for Bison.
If you need more information on reproducing
this reported
issue please let me know and I will provide
the entire
build and source code with compiler
projects and settings.
I would also like to know for my own usage
if this really
is a problem to be concerned with.
For now, I will keep
"lint" defined and prevent the program from
crashing in
the epilogue stage of parsing.
Best regards,
Brian,
P.S.
I have included my "MSDOS" version of
subpipe.c (subpipe_msdos.c)
and the required changes to output.c for
directory slashes "\\"
in msdos v.s. "/" in Unix. Some debug
code still exists in the
source I provided. I have also
provided my sample input for
Bison that causes the program to
crash.
|
subpipe_msdos.c
Description: Text document
output.c
Description: Text document
config.h
Description: Text document
calc.y
Description: Binary data
[Prev in Thread] | Current Thread | [Next in Thread] |