Skip to content

Initialize encoding/decoding buffers with null pointers closes #1#3

Merged
EndPositive merged 1 commit intomainfrom
fix/ptr-nullify
Jun 9, 2025
Merged

Initialize encoding/decoding buffers with null pointers closes #1#3
EndPositive merged 1 commit intomainfrom
fix/ptr-nullify

Conversation

@EndPositive
Copy link
Owner

the caller has no way to know if they need to free it or not

while this is not necessarily true--the buffer is only allocated on succesful return codes--it is indeed better practice to ensure the pointers are nullified. This prevents future accidental mal-use leading to corruption when freeing an uninitialized pointer.

closes #1

> the caller has no way to know if they need to free it or not

while this is not necessarily true--the buffer is only allocated on succesful return codes--it is indeed better practice to ensure the pointers are nullified. This prevents future accidental mal-use leading to corruption when freeing an uninitialized pointer.
@EndPositive EndPositive requested a review from x-stp June 6, 2025 10:12
Copy link
Collaborator

@x-stp x-stp left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks solid!

a bit out of scope, but the slipstream_packet_loop_ func may leak mem when either encode/ decode callbacks allocate memory -> report an error (by returning a value <= 0). The loop immediately exits or continues defer / freeing the memory that was allocated; besides that

LGTM!

@EndPositive EndPositive merged commit 282764a into main Jun 9, 2025
@EndPositive EndPositive deleted the fix/ptr-nullify branch June 9, 2025 05:42
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.

2 participants