Skip to content

Commit

Permalink
[3.12] gh-123229: Fix valgrind warning by initializing the f-string b…
Browse files Browse the repository at this point in the history
…uffers to 0 in the tokenizer (GH-123263) (#123265)

(cherry picked from commit adc5190)

Signed-off-by: Pablo Galindo <[email protected]>
  • Loading branch information
pablogsal authored Aug 23, 2024
1 parent 8fe586d commit 7dec3d7
Show file tree
Hide file tree
Showing 3 changed files with 16 additions and 1 deletion.
Original file line number Diff line number Diff line change
@@ -0,0 +1,2 @@
Fix valgrind warning by initializing the f-string buffers to 0 in the
tokenizer. Patch by Pablo Galindo
2 changes: 1 addition & 1 deletion Parser/tokenizer.c
Original file line number Diff line number Diff line change
Expand Up @@ -65,7 +65,7 @@ static const char *type_comment_prefix = "# type: ";

static struct tok_state *tok_new(void) {
struct tok_state *tok =
(struct tok_state *)PyMem_Malloc(sizeof(struct tok_state));
(struct tok_state *)PyMem_Calloc(1, sizeof(struct tok_state));
if (tok == NULL)
return NULL;
tok->buf = tok->cur = tok->inp = NULL;
Expand Down
13 changes: 13 additions & 0 deletions lel.patch
Original file line number Diff line number Diff line change
@@ -0,0 +1,13 @@
diff --git a/Parser/tokenizer.c b/Parser/tokenizer.c
index 3118fb19846..9e0dee8cc38 100644
--- a/Parser/tokenizer.c
+++ b/Parser/tokenizer.c
@@ -65,7 +65,7 @@ static const char *type_comment_prefix = "# type: ";

static struct tok_state *tok_new(void) {
struct tok_state *tok =
- (struct tok_state *)PyMem_Malloc(sizeof(struct tok_state));
+ (struct tok_state *)PyMem_Calloc(1, sizeof(struct tok_state));
if (tok == NULL)
return NULL;
tok->buf = tok->cur = tok->inp = NULL;

1 comment on commit 7dec3d7

@julian-smith-artifex-com

Choose a reason for hiding this comment

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

While this fix undoubtedly works, it makes the code a little inconsistent - previously it exhaustively set each member of the struct tok_state, most of them to zero or NULL. But it now it relies on PyMem_Calloc() to initialise at least one member, in an implementation-defined way that usually corresponds to zero or NULL.

If we are happy to assume that PyMem_Calloc()'s strictly undefined behaviour here is ok in practice, should we remove all the explicit settings to zero or NULL? Otherwise maybe it would be better to revert back to PyMem_Malloc() and add code to explicitly set the new member(s)?

Please sign in to comment.