toke.c - only try to shrink an SV buffer when conceivably possible #23293
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.
A few places within toke.c try to return unused string buffer space by doing something like:
The rationale for the
5is not commented upon. Maybe it's a random thumb in the air, maybe it was 1 byte for the trailing null plus a 4 byte pointer to account for allocation alignment?Either way, on a platform with 8 byte pointers, that code could try to shrink buffers when there's no realistic chance of doing so. (The space between chunk sizes will be at least 1x
PTRSIZE, often 2xPTRSIZEat smaller sizes and then progressively more.)For a reallocation that is at least has the potential to be meaningful, the difference between CUR and LEN should be at least:
PTRSIZEThis commit changes makes that so.