Skip to content

Conversation

@zherczeg
Copy link
Collaborator

@zherczeg zherczeg commented Nov 20, 2025

I hoped the memory can be reduced this way, but no luck so far. The size before eptr is 80 bytes before and after the patch, since char_repeat uses all members. However, due to using a struct type, we might be able to reduce the size of some members in the future.

@zherczeg zherczeg force-pushed the match_stack branch 2 times, most recently from 2ddd780 to ea954db Compare November 20, 2025 14:15
mb->true_end_subject = mb->end_subject + P->temp_size;
Feptr = P->temp_sptr[1];
F->fields.op_assert_scs.saved_end_subject = mb->end_subject;
mb->end_subject = P->fields.op_assert_scs.saved_end_subject;

Check warning

Code scanning / clang

Dereference of null pointer Warning

Dereference of null pointer
Copy link
Member

Choose a reason for hiding this comment

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

We can just ignore this. Clang's static analyzer is usually very helpful, but it has some spammy false positives in this file, due to the goto-based architecture. It thinks it's possible for there to be NULLs, because it can't follow all the conditions across the gotos.

Copy link
Member

@NWilson NWilson left a comment

Choose a reason for hiding this comment

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

I like it! Better names is good.

#define Lmin F->fields.char_repeat.min
#define Lmax F->fields.char_repeat.max
#define Lc F->fields.char_repeat.c
#define Loc F->fields.char_repeat.oc
Copy link
Member

Choose a reason for hiding this comment

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

Do you know why some of the defines are "Lsomething" and some are "Fsomething"? Is it just inconsistent naming?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I suspect L is local, and F is frame. So L-s may or many not present in a frame, but F-s are always present and have the same meaning. Of course only @PhilipHazel knows the exact meaning. :)

Copy link
Collaborator

Choose a reason for hiding this comment

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

@zherczeg is correct. The naming is definitely deliberate. There is this comment in the code:

/* Define short names for general fields in the current backtrack frame, which
is always pointed to by the F variable. Occasional references to fields in
other frames are written out explicitly. There are also some fields in the
current frame whose names start with "temp" that are used for short-term,
localised backtracking memory. These are #defined with Lxxx names at the point
of use and undefined afterwards. */

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I have updated the comments.

mb->true_end_subject = mb->end_subject + P->temp_size;
Feptr = P->temp_sptr[1];
F->fields.op_assert_scs.saved_end_subject = mb->end_subject;
mb->end_subject = P->fields.op_assert_scs.saved_end_subject;
Copy link
Member

Choose a reason for hiding this comment

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

We can just ignore this. Clang's static analyzer is usually very helpful, but it has some spammy false positives in this file, due to the goto-based architecture. It thinks it's possible for there to be NULLs, because it can't follow all the conditions across the gotos.

@zherczeg zherczeg merged commit 954a921 into PCRE2Project:main Nov 21, 2025
21 checks passed
@zherczeg zherczeg deleted the match_stack branch November 21, 2025 08: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.

3 participants