#1 fpgac fails to check malloc error returns

open
nobody
None
5
2005-11-28
2005-11-28
John Bass
No

fix for [ fpgac-Bugs-1367682 ] fpgac fails to check
malloc error returns

Discussion

  • John Bass

    John Bass - 2005-11-28

    Fix for fpgac.y malloc error checks

     
  • isaac pentinmaki

    Logged In: YES
    user_id=973287

    Why calloc instead of malloc ?
    The return values should be the same and seems like it just
    makes it non-intuitive if you need to search for all the
    mallocs.

    Also you could eliminate some of the mallocs by changing
    the declaration of YYSTYPE to include a value field for
    doing the integer constant folding. That will reduce
    fragmentation and heap usage.
    names.h:
    typedef union {
    struct variable *v;
    char *s;
    int type;
    long value; // use this in intop etc
    } YYSTYPE;

    http://somewhere/bison_6.html#SEC45
    Alternatively, you can specify the data type when you refer
    to the value, by inserting `<type>' after the `$' at the
    beginning of the reference. For example, if you have
    defined types as shown here:

    %union {
    int itype;
    double dtype;
    }

    then you can write $<itype>1 to refer to the first subunit
    of the rule as an integer, or $<dtype>1 to refer to it as a
    double.

     
  • Nobody/Anonymous

    Logged In: NO

    The reason for using calloc is that it clears memory, and
    malloc may return dirty memory if the memory is reused. This
    is important, as with malloc if you add a new member to a
    structure which needs zero initialization, you would also
    need to locate every instance where it is allocated and
    manually add code to clear the new structure member.

    Thus using calloc by policy removes one source of
    non-initialized memory bugs that have potentially random
    failures.

    With the exception of a few varlist structures, and the hash
    table used for dup checking, all allocated memory is held
    till program completion in fpgac. The earliest most of the
    allocated data can be free'ed is right after prune, IF there
    was a good way to know all items that are no longer
    required. Next step is dumping the net list, followed by
    program termination.

    As for having bison manage allocation for parser objects, if
    that feature is also in YACC, it may well be something we
    want to do for cleanup. I believe the current code will
    compile and run under native UNIX systems without GNU tools.
    If we decide to break that, there should be good reason.

     
  • Nobody/Anonymous

    Logged In: NO

    YACC and Bison both have the union feature. The fpgac.y
    source uses explicit field references anyway
    ie $$.v

    The calloc's are fine.

    The calloc's are all followed by explicit assignments in
    all code paths that I see. The only dubious one may be
    sprintf(temp->name, "T%d_%dL%d_%s", thread, ...
    which for an edge case perhaps exceed the memory allocated,
    though the maxnamelen of 128 would make it difficult.

    The strings being generated by intop I think will become
    dangling heap objects in a complex expression, as it seems
    to be doing constant propagation.
    i.e. 2 || 4 || 8

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks