3 ms·
Right, that makes more sense, could have guessed that tick() shouldn't be const :) (You missed one more detail though: In the implementation of yl_task_get_res
by adsche 13y ago
Right, that makes more sense, could have guessed that tick() shouldn't be const :)
(You missed one more detail though: In the implementation of yl_task_get_result_string, it should be AS_CTYPE now.)
Another question, different topic, about the memory allocations: In your example, why do you provide implementations for calloc and strdup instead of letting them be set as well? I do agree with your stance on (not) dealing with allocation failures in the library. But if I as a library user use (anything like) standard malloc (and NULL pointer checks after e.g. yl_*_new()) I would probably be annoyed at your implementations of calloc and strdup (which would crash somewhere in your library when malloc returns NULL).
- the_mitsuhiko 13y ago> why do you provide implementations for calloc and strdup instead of letting them be set as well. For me personally it's because I never use calloc religiously. I implement calloc so that I can forward those allocators to my dependencies (like curl). I guess you have a point there. With regards to strdup: My version changes the interface in that it's allowed to pass NULL through it in my own code. I know I did not do that in the blog post because I did not want to start a discussion about that API change :-)
- adsche 13y agoThanks for the answers. Great writeup altogether :-) test.py sounds interesting, maybe I'll look into that some time.