itkDB dbGetCellViewViewName

[Ike Naar]

Hopefully someone can help me with this.
I'm using the itkDB C interface functions to access a CDBA database.
Some of the "get" functions return a C string (pointer to char), e.g.

extern String dbGetCellViewViewName(dbCellViewId);

dbCellViewId id = /* assume a meaningful value */;
char * viewname = dbGetCellViewViewName(id);

The question is: who owns the memory that is returned by the function
(here, the string ``viewname'') ?
Is it owned by the database? By the caller?
Is it safe to modify the string?
Is it necessary to free the string after having finished with it?

Kind regards,
Ike

 

[Andrew Beckett]

Ike Naar wrote, on 02/24/09 22:52:

Hopefully someone can help me with this.
I'm using the itkDB C interface functions to access a CDBA database.
Some of the "get" functions return a C string (pointer to char), e.g.

extern String dbGetCellViewViewName(dbCellViewId);

dbCellViewId id = /* assume a meaningful value */;
char * viewname = dbGetCellViewViewName(id);

The question is: who owns the memory that is returned by the function
(here, the string ``viewname'') ?
Is it owned by the database? By the caller?
Is it safe to modify the string?
Is it necessary to free the string after having finished with it?

Kind regards,
Ike

Ike,

Strings returned by these functions are what we call "PermStrings". Without
going into the details of the implementation, the memory is managed by the
Cadence code, and you must NOT modify the value nor free the memory afterwards.

The memory is "permanently" allocated, but this is done in a smart way to avoid
a continual leakage of memory when you have repeated calls.

Regards,

Andrew.

 

[Ike Naar]

In article <49a563c2$1@news.cadence.com>,
Andrew Beckett <andrewb@DcEaLdEeTnEcTe.HcIoSm> wrote:

Ike Naar wrote, on 02/24/09 22:52:
[about extern String dbGetCellViewViewName(dbCellViewId)]
Strings returned by these functions are what we call "PermStrings". Without
going into the details of the implementation, the memory is managed by the
Cadence code, and you must NOT modify the value nor free the memory afterwards.

Thanks Andrew. I'm doing maintenance on existing C code that clobbers
such memory (e.g. by overwriting a character in the middle of a string
with a null character, in order to truncate the string).
I'll see if I can rewrite that code.