I don't think this fix is correct - existing 3rd party code which calls caml_strdup will use free, not caml_stat_free and so break, I think?

My understanding was that caml_stat_free is only required when the runtime is explicitly started with caml_startup_pooled, and then the behavior that you ( @dra27 ) descibe looks correct to me: in this not-the-default mode we want legacy code to break so that it is fixed to preserve the desired invariants.

@gasche is correct: if the runtime is not started with caml_startup_pooled, then no breakage should occur. The end user should experience no regressions, unless he explicitly chooses the new pooling mode.

From a comment in memory.h: "If the pool is not initialized, [caml_stat_*] functions will still work in backward compatibility mode, becoming thin wrappers around [malloc] family of functions".

Ah, gotcha - I had overlooked/forgotten the difference between normal startup and caml_startup_pooled. Perhaps the Changes entry for GPR#71 could be updated to include this GPR, just for any future reference?

My only other thought is if we want to do anything with warning pragmas to show the deprecation, but I expect that we don't want to do that, at this stage, for 4.06.0?

Merged in trunk, cherry-picked in 4.06 ( 84a29f4 ).