Skip to content

Conversation

@khwilliamson
Copy link
Contributor

These commits change this private function to avoid some recalculations, and speed up the common case where these binary-like numbers have leading zeros. And two flags that should have been returned were not.

  • This set of changes does not require a perldelta entry.

Clarify some comments.
I noticed that leading zeros are quite common for octal and hex
constants.  This code is structured for speed, with a partially unrolled
loop structured so that it is impossible to overflow the unrolled part.

If we get to the end of the unrolled portion, and the accumulated value
is still zero, it's because there have been only leading zeroes so far,
and instead of dropping into the loop, we can re-enter the unrolled part
without having to consider the possibility of overflowing.  This allows
the next chunk of digits to be processed without branching.
It's easier to understand and code if each flag name is for a single
flag.
Apparently no one has tried to use these before.  These flags are to
suppress the display of certain warnings, but to instead return that the
suppression happened in output flags.  The output flags were not getting
set.

I'm not adding a separate test, because a future commit will cause this
feature to be used regularly.
We already have this value in a variable.
The new scheme is is what toke.c already uses for the same purpose, and
I think is cleaner
This prevents a future maintainer from accidentally changing this
pointer inside the function, where its original value is needed at the
end
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