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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Fix for fpgac.y malloc error checks
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.
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.
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