User-defined memory functions about concord

[lcsmuller]

Hello @notcancername, I think anything that adds customizability to concord while also being fully backwards compatible is a win in my book.

Not sure if it's in your plans, but to make sure this works well I think we should also implement some custom dynamic memory functions of our own for when concord is built on debug mode (memory tracking purposes). This should give us a good idea if the implementation makes sense.

I may underestimate the scope of this change

You might be a little bit, but we'll see how it goes!

[HackerSmacker]

I'm about a day delinquent on this, so, let me compose a long and supposedly eloquent response. I'll do this as a bulleted list:

malloc output isn't being checked!
Honestly, personally, I feel that if malloc is failing, there are now other issues that are out of the scope of Concord. It could be a memory exhaustion issue (in which case, something somewhere else is about to start suffering, the OS is paging aggressively, or there is some hardware fault with the memory (I don't know of any OSes that report this as a failed malloc, usually it'll just emit a message on the operator console and hope the system operator is smart enough to shut the system down and do hardware repair). If malloc fails for whatever reason, I think a message should be logged somewhere, as that could be implicative of some other issues somewhere else. This should definitely be checked.

Signal safety need not apply!
Why not be signal-safe? Granted, it's hard to implement, but, like all good things in life, one must consider if this is really necessary or not -- I personally don't think it'll be an issue (you don't have to use SIGALRM because you can use a Discord timer), but it could be a very specific use-case thing. Should someone require it, they can implement it on their end since I don't think this is a pressing matter.

Debugging purposes
This is an extremely good reason in my book. "Back in the day," there were (and still are, look at Android's libc) so-called "debugging malloc" libraries that would aid with debugging programs that don't work so well. With tagged debugging information within Concord, debugging information would be more sophisticated than some basic lowest-common-denominator stuff. I think this is reason enough to implement this proposal.

Other language support
Ideally, for other languages, you don't want to pull control out of their runtime library with random C library functions -- this could especially be an "issue" in languages that have more sophisticated memory-safety features that don't look too positively upon hidden-away memory allocation or freeing.

Using a GC with Concord
That'd be an interesting concept, but, I don't know if anyone's really looking for that per se, most C programmers look down upon the idea of garbage collection, since all of that was figured out ahead-of-time in the program implementation stage. Nonetheless, it'd be a cool technical feat!

[notcancername]

malloc error checking

I agree. The system functions installed by ccord_global_init check the return value.

why no signal safety

mmap(2) is not AS-safe. fprintf, which is used for error reporting, is not AS-safe.

debug malloc

Seems reasonable, I probably won't implement this in this proposal though. It would also require some fairly unclean macro hackery.

other language support

I agree.

GC

fair

[HackerSmacker]

The printf family is a classic example because you can (quite easily) get two strings mixing together on the terminal. Fortunately, I don't think it'll be a massive issue for us at all, since we basically don't ever handle signals. I think that weeds out most of the possible issues!