Project

General

Profile

Bug #4

Making the new IDMEF API more consistant: refcount

Added by Yoann VANDOORSELAERE almost 20 years ago. Updated almost 15 years ago.

Status:
Closed
Priority:
Normal
Target version:
-
Start date:
Due date:
% Done:

0%

Resolution:
fixed

Description

Currently, it is said that an object inserted into the IDMEF tree should not be touched by the caller anymore. This lead to problem in very common and simple case where it's more natural to code thing that way :

<pseudo code>
idmef_time_t *time;

time = idmef_time_new_gettimeofday();
if ( ! time ) { whatever }

idmef_alert_set_create_time(alert, time);
idmef_alert_set_detect_time(alert, time);
</pseudo code>

This code look like valid for most developers, however, it will lead to a crash on idmef_message_destroy() because we lack handling refcount support on specific object operation.

The proposal is as follow:

- idmef_xxx_t *idmef_xxx_new():
On standalone object creation, the object refcount should
be set to 0.

- idmef_xxx_t *idmef_yyy_new_xxx():
On creation of a children object, linked to a parent
object, the refcount should be set to 1.

- idmef_yyy_set_xxx(idmef_yyy_t *yyy, idmef_xxx_t *xxx)
When linking a standalone object to it's parent, it's refcount should be incremented.
incremented.

History

#1 Updated by Yoann VANDOORSELAERE over 19 years ago

  • Status changed from New to Closed
  • Resolution set to fixed

Now that every IDMEF object got a refcount, this problem has been solved. Agreement has been reached to keep the way IDMEF object memory is handled explicit to the user, using the ref/unref mechanism.

#2 Updated by Yoann VANDOORSELAERE almost 15 years ago

  • Project changed from PRELUDE SIEM to Libprelude
  • Category deleted (1)

Also available in: Atom PDF