[Open-scap] RE: OVAL Model Memory Management

David Niemoller David.Niemoller at g2-inc.com
Tue Aug 4 14:47:45 UTC 2009


I'm in agreement with all your suggested changes except 1.  You are
correct in your analysis that if consumer functions do NOT create copies
of the value variable, then freeing it in oval_parser_text_value is not
a good thing.  However, it is the case that most of the consumers that
hold onto the variable create a copy to hold the content.  It was my
intention that all such consumers create copies, however, I missed two
of them (oval_value_parse_tag_consume_text in oval_value.c and
oval_text_consumer in oval_parser.c (my face is red..that's right next
door)).  I'm banging together a patch that fixes these two places and
replaces malloc_string with strdup as you suggest.

-----Original Message-----
From: Peter Vrabec [mailto:pvrabec at redhat.com] 
Sent: Tuesday, August 04, 2009 9:27 AM
To: David Niemoller
Cc: open-scap-list at redhat.com
Subject: Re: OVAL Model Memory Management

Hi David,

thnx a lot for the patch. It was already pushed into repository, but I
had to 
do same changes in order to pass test cases. Please take a look at my
commit.

http://git.et.redhat.com/?p=openscap.git;a=commitdiff;h=fcc8fef051151f78
b5e7a03ef906be69d73c6f06

IMPORTANT
1. I have removed free(value) from oval_parser_text_value(), because 
"consumer" functions do NOT create copy of value variable.

MINOR
2. set variable->comment = NULL in oval_variable_new()

3. I have changed oval_value_boolean() to return bool type

btw. Can we replace malloc_string() by strdup()?
malloc_string():
        char *temp = (char *)malloc((strlen(string) + 1) * sizeof(char)
+ 1);
Why there is the last "+1" in ^


Peter.

On Monday 03 August 2009 11:07:57 pm David Niemoller wrote:
> The attached source patch (against the openscap master head as of 3
Aug
> 2009) contains my updates to oval model heap management.  I've
> structured these updates around more consistent patterns for memory
> allocation/deallocation than is characteristic of my earlier entries.
I
> believe these updates address most if not all of the problematic
> allocations, particularly those that involve the passing of character
> content from the XML parser to the object and syschar models.





More information about the Open-scap-list mailing list