bug-bison
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Fw: Bison-1.875 Bug Report


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,
 
Brian Howse, P.Eng.
address@hidden
 
 
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.
 
 

Attachment: subpipe_msdos.c
Description: Text document

Attachment: output.c
Description: Text document

Attachment: config.h
Description: Text document

Attachment: calc.y
Description: Binary data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]