Skip to content

Fix: inconsistent use of caml_stat_* functions#68

Closed
murmour wants to merge 1 commit intojanestreet:masterfrom
murmour:master
Closed

Fix: inconsistent use of caml_stat_* functions#68
murmour wants to merge 1 commit intojanestreet:masterfrom
murmour:master

Conversation

@murmour
Copy link

@murmour murmour commented Jan 3, 2016

Hello. I'm doing a large-scale study of C stub sources on OPAM.

Your library makes use of the undocumented caml_stat_* functions, which currently are thin wrappers around malloc, realloc, and free from the C standard library. In future, the implementation of these functions may change, making them incompatible with malloc and breaking the code that abused the old undocumented semantics.

Regardless of whether the change of semantics will happen or not, being consistent about such matters should be considered good style.

@murmour
Copy link
Author

murmour commented Jan 3, 2016

If caml_stat_free were to adopt a different semantics, many of its occurrences would need to be moved outside of "blocking sections".

Thank you for raising this important point.

I'm pretty sure that caml_stat_free will never require a runtime lock, since way too many packages depend on the current behavior -- it would be a major breakage of C stubs across OPAM. On the other hand, situations when caml_stat_* are used inconsistently with the malloc family of functions are quite rare, as my study shows so far (aggregated results will soon follow).

By the way, right now I'm investigating some probable leaks inside your excellent sqlite3 package. Stay tuned :-)

@hhugo
Copy link

hhugo commented Sep 1, 2019

This is available on master

@hhugo hhugo closed this Sep 1, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants