$darkmode
Elektra 0.11.0
|
A problem with having elektraMalloc
et al.¹ is, that:
You might even do that by accident and never notice the problem, until someone replaces elektraMalloc and then you could get some pretty bad memory bugs.
¹ Affected functions:
elektraMalloc
elektraCalloc
elektraFree
elektraStrDup
elektraStrLen
Proprietary apps are sometimes delivered together with a libc (either static or a startup script makes sure their own libs are found). If they would use Elektra, and the person wants the app to use the global Elektra it is a valid use case for the dedicated functions.
The only safe way to keep elektraMalloc et al. is to define that they will always call their libc counterpart (malloc et al.) and their purpose is simply to add assertions. Then we can also make them private, because you can just call free to free any pointer returned by Elektra.
elektraMalloc
/ elektraCalloc
with simple calls to mallocelektraFree
from public APIelektraStrLen
, elektraStrCmp
)elektraStrNDup
and other stdlib
equivalents that do memory allocation.While the current state might cause some problems with compiler optimizations and discoverability, those issues probably are only very minor in practice. Removing all functions poses a considerable amount of work, which would have to be undone in case we need those functions one day anyway. The current downsides don't justify such a big procedure.
@kodebach wrote: Ideally, I'd remove the functions, but it seems unlikely this will be accepted.