WCSLIB  5.16
Memory management

The initialization routines for certain of the WCSLIB data structures allocate memory for some of their members:

The caller may load data into these arrays but must not modify the struct members (i.e. the pointers) themselves or else memory leaks will result.

wcsini() maintains a record of memory it has allocated and this is used by wcsfree() which wcsini() uses to free any memory that it may have allocated on a previous invokation. Thus it is not necessary for the caller to invoke wcsfree() separately if wcsini() is invoked repeatedly on the same wcsprm struct. Likewise, wcsset() deallocates memory that it may have allocated on a previous invokation. The same comments apply to linini(), linfree(), and linset() and to tabini(), tabfree(), and tabset().

A memory leak will result if a wcsprm, linprm or tabprm struct goes out of scope before the memory has been free'd, either by the relevant routine, wcsfree(), linfree() or tabfree(), or otherwise. Likewise, if one of these structs itself has been malloc'd and the allocated memory is not free'd when the memory for the struct is free'd. A leak may also arise if the caller interferes with the array pointers in the "private" part of these structs.

Beware of making a shallow copy of a wcsprm, linprm or tabprm struct by assignment; any changes made to allocated memory in one would be reflected in the other, and if the memory allocated for one was free'd the other would reference unallocated memory. Use the relevant routine instead to make a deep copy: wcssub(), lincpy() or tabcpy().