Update POD for Newx/Renew/Safefree vs libc analogs about heap corruption #22682
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
bulk88
force-pushed
the
pod_PL_xs_c_mem_alloc
branch
from
714fa49
to
c769b6d
Compare
This isn't documented anywhere except in perlapi, in the per-macro/per-function section. A seasoned dev, will read perlguts ONCE, write code, then pass a Newx() pointer, to some 3rd party library or native OS API, and then instant disaster, or invisible disaster. If Newx() and libc malloc() pointers are interchangeable, on ONE particular OS, with ONE particular perl build, with ONE particular set of build flags, that is undefined behavior. Have fun with #define USE_MDH or -DUSE_MDH or -DDEBUGGING or #define MYMALLOC -DMYMALLOC. Also, for anyone reading this in the future. DO NOT EVER DOCUMENT the permutations where Newx() is libc malloc(). Perl core reserves the right, to separate Newx() and malloc(), at any time in a maint release if there are technical reasons to do so. Also libperl.so/.dll embedders, if libperl is unloaded from the process, and deallocs all Newx() blocks globally, and a 3rd party library still loaded in the process, thinking it owns that "malloc()" block, that was given ownership of, in 3rd party lib API contract, SEGV time.
bulk88
force-pushed
the
pod_PL_xs_c_mem_alloc
branch
from
c769b6d
to
a6d613c
Compare
khwilliamson
requested changes
Nov 27, 2024
|
|
||
| XXX Description of the change here | ||
| Documentation was updated to reflect that mixing C<Newx>, C<Renew>, and | ||
| C<Safefree> vs C<malloc>, C<realloc>, and C<free> not allowed, and mixing |
There was a problem hiding this comment.
missing the verb are here
|
Yeah, this is an interesting footgun that does deserve being document. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This isn't documented anywhere except in perlapi, in the per-macro/per-function section. A seasoned dev, will read perlguts ONCE, write code, then pass a Newx() pointer, to some 3rd party library or native OS API, and then instant disaster, or invisible disaster. If Newx() and libc malloc() pointers are interchangeable, on ONE particular OS, with ONE particular perl build, with ONE particular set of build flags, that is undefined behavior. Have fun with #define USE_MDH or -DUSE_MDH or -DDEBUGGING or #define MYMALLOC -DMYMALLOC.
Also, for anyone reading this in the future.
DO NOT EVER DOCUMENT the permutations where Newx() is libc malloc().
Perl core reserves the right, to separate Newx() and malloc(), at any time in a maint release if there are technical reasons to do so.
Also libperl.so/.dll embedders, if libperl is unloaded from the process, and deallocs all Newx() blocks globally, and a 3rd party library still loaded in the process, thinking it owns that "malloc()" block, that was given ownership of, in 3rd party lib API contract, SEGV time.