| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
| |
This is supposed to test weird combinations of things. Tests like
'ss' =~ /SS/i
aren't weird, and so can be skipped.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Consider U+FB05 and U+FB06. These both fold to 'st', and hence should
match each other under /i. However, Unicode doesn't furnish a rule for
this, and Perl hasn't been smart enought to figure it out. The bug that
shows up is in constructs like
"\x{fb06}" =~ /[^\x{fb05}]/i
succeeding. Most of these instances also have a 'S' entry in Unicode's
CaseFolding.txt, which avoids the problem (as mktables was earlier
changed to include those in the generated table). But there were
several code points that didn't.
This patch changes utf8.c to look for these when constructing it's
inverted list of case fold equivalents. An alternative would have been
to change mktables instead to look for them and create synthetic rules.
But, this is more general in case the function ends up being used for
other things.
I will change fold_grind.t to test for these in a separate commit.
|
| |
|
|
|
| |
This comment will no longer apply, as the code it talked about is
moving into swash_init().
|
| |
|
|
|
|
|
|
| |
Many of the mapping tables that utf8_heavy.pl deals with have maps that
don't fit into the general scheme of things, and a hash is generated for
those. This patch causes utf8_heavy to add an entry to the object it
generates containing a reference to this hash. Prior to this, the name
of the hash had to be known to the users of the table.
|
| | |
|
| |
|
|
|
|
| |
mktables creates %utf8::SwashInfo in each table it generates, giving
some info about the table. Add an entry to this for tables that have
a hash of special mappings, giving the name of that hash.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
av_len() is misnamed, and hence led me earlier to stop the loop
one shy of what it should have been. No actual bugs were caused by
this, but it could cause a duplicate entry in an array, which is
searched linearly, hence a slight slowdown.
|
| |
|
|
|
|
|
| |
This causes run_test() to be part of the subtests, and makes a subtest
for each pair of code points tested plus the character set. This
results in fewer tests output, plus more information about what's
happening
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Previously these were skipped. Now skip just the ones that don't make
sense or aren't implemented.
|
| |
|
|
|
| |
These two characters fold to lower-case characters that are involved
in tricky folds, and hence these can be too.
|
| |
|
|
|
|
|
|
|
|
|
| |
This new podcheck.t catches more problems, and tests more pods than
the current one, while suppressing some existing warnings that really
aren't problems.
It takes longer to execute. I have profiled it, and most of the increased
time appears to be because of testing more pods.
A complete pod for its usage is included
|
| |
|
|
|
|
| |
The =apidoc entries for hv_clear() and hv_undef() were a bit spartan.
Make it clearer what the two functions actually do, and the relationship
between them.
|
| |
|
|
|
|
|
|
|
| |
The recent commits to make sv_clear() iterative when freeing a hash,
introduced a bug. If the hash only has one key, and that becomes the
iterator, and is then deleted; then when the hash is freed, the LAZYDEL
feature is skipped, and the iterated hash value fails to get deleted.
The fix is simple: check for LAZYDEL before return is keys == 0.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
followup to previous commit. I'm fairly confident now that a HV being
freed in sv_clear() can never get re-blessed, and thus its SvSTASH field is
*always* safe to use.
The logic behind this is that once you get to sv_clear(), the HV has a
refcnt of zero, which means either:
* nothing references this, so there's no way to bless it;
* we're in SVf_BREAK territory, in which case something may still
hold a reference to it, but all destructors will have already been
called, so nothing can call bless.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
make sv_clear() iteratively free the elements of a hash, rather than
recursing. This stops freeing deeply nested hash of hash structures from
blowing the stack.
This commit is relatively straightfoward, now that
a) the infrastruure is already in place in sv_clear to iteratively
free AVs;
b) the long sequence of commits leading up to this has provided us with
the hfree_next_entry() function, which returns just the next sv in the
hash that needs freeing.
When starting to free a new hash, we have to save the old value of iter_sv
somewhere; we do this by sticking it in the unused SvSTASH slot of the HV.
This slot shouldn't get messed with, since, but this time we've already
called the destructor on this object, and we should have a refcount of
zero, so no destructor should be able to see us to rebless us.
Ideally we'd like to be able to save the old index into HvARRAY when
freeing a new HV, but I couldn't think of anywhere to hide it.
So we get sub-optimal scanning of the parent's HvARRAY when freeing hashes
of hashes.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Move body of hfreeentries()' central loop into a new function,
hfree_next_entry(); leaving hfreeentries() as a simple loop that calls
hfree_next_entry() until there are no entries left.
This will in future allow sv_clear() to free a hash iteratively rather
than recursively.
Similarly, turn hv_free_ent() into a thin wrapper around a new function,
hv_free_ent_ret(), which doesn't free HeVAL(), but rather just returns the
SV instead.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently perl attempts to clear a hash 100 times before panicking.
So for example, if a naughty destructor keeps adding things back into the
hash, this will eventually panic.
Note that this can usually only occur with %h=() or undef(%h), since
when freeing a hash, there's usually no reference to the hash that a
destructor can use to mess with the hash.
Remove this limit (so it may potentially loop forever).
My reasoning is that (a) if the user wants to keep adding things back into
the hash, who are we to stop her? (b) as part of of the process of making
sv_clear() non-recursive when freeing hashes, I'm trying to reduce the
amount of state that must be maintained between each iteration.
Note that arrays currently don't have a limit.
|
| |
|
|
|
|
|
| |
Move the freeing of the SV from near the beginning to the end of
hv_free_ent(); i.e. free the HE before the SV. Ideally, this should cause
no change in behaviour, but will make using an iterative HV freeing
scheme easier.
|
| |
|
|
|
| |
Now that HV backrefs are only stored in HvAUX, don't go looking for them
in magic too in sv_clear()
|
| |
|
|
|
| |
The code path that leads to HvAUX being empty and thus HvARRAY being
freed, is non-obvious: so put in an assert against any future failure.
|
| |
|
|
|
|
|
|
|
| |
S_hfreeentries() has two nested infinite loops: the inner one
does one sweep through all buckets, freeing all entries in each bucket;
the outer loop repeats the process if new keys have been added in the
meantime.
Collapse these two into a single 'while (keys) {}' loop.
Should be functionally the same, but simpler.
|
| |
|
|
|
|
|
| |
Formerly, hv_clear() and hv_undef() zeroed the contents of
HvARRAY after calling hfreeentries(), but that sub now zeroes
each elements as a by-product of its deleting algorithm.
So we can skip the Zero().
|
| |
|
|
|
| |
Now that HV backref data is always stored in HvAUX and never in magic,
update the various backref handling functions to account for that.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, when empting a hash of its elements (e.g. via
undef(%h), or %h=()), HvARRAY field is temporarily zeroed, so that
any destructors called on the freed elements see an empty hash.
Change this so that they see any remaining elements. Thus,
%h=() becomes more like C<delete $h{$_} for keys %h>.
The atomic behaviour was introduced (by me) in 2003 with commit
2f86008e34264, to fix RT #3096. This concerned element destructors
that messed with the hash being undeffed, causing unrefed var errors
and the like.
At the time, simply setting HvARRAY to null for the duration seemed like a
simple fix. However, it didn't take account of destructors adding new
elements to the list, thus re-creating HvARRAY. This was subsequently
fixed. Then, the HvAUX structure was invented, which meant that optional
hash fields were hidden away at the end of HvARRAY. This meant that
hfreeentries() acquired a whole bunch of extra code to copy these fields
around between the original HvARRAY and the new HvARRAY and then back
again, and temporarily squirrelling the backref array in backref magic
rather than in HvAUX.
In short, hfreeentries() became a 200 line sprawling mess.
This commit reduces it back to 70, and makes everything conceptually
simpler.
It does however change user-level visible behaviour (back to pre-2003),
but note that the new behaviour now matches the behaviour that arrays have
always had (i.e. destructors see a partially-emptied array).
Note that backref magic for HVs is now always stored in HvAUX
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Those two macros expand into two large, almost identical chunks of code.
The only difference between the two is the source of the hash seed.
So parameterize this into a new PERL_HASH_INTERNAL_() macro.
Also, there are a couple of places in hv.c that do the rough equivalent of
if (HvREHASH(hv))
key = PERL_HASH_INTERNAL(...)
else
key = PERL_HASH(...)
which incorporates two complete macro expansions into the code.
Reorganise them to be
key = PERL_HASH_INTERNAL_(..., HvREHASH(hv))
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Don't use a goto when an else will do
i.e. replace
if (..) {
A
goto reset
}
B
reset:
with
if (..) {
A
}
else {
B
}
|
| |
|
|
| |
Signed-off-by: Michael Witten <mfwitten@gmail.com>
|
| | |
|
| |
|
|
|
|
| |
cmp_version.t was complaining.
Why does this even *have* a version?
|
| | |
|
| |
|
|
| |
because of the upcoming patch
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
System header conversion with "h2ph -a" is currently broken on Ubuntu
Natty and Oneiric (unless the gcc-multilib package is installed for
backward compatibility), resulting in things like
# perl -e 'require "syscall.ph"'
Can't locate asm/unistd.ph in @INC [...]
This happens because Ubuntu has switched to a 'multiarch' setup, see
<https://wiki.ubuntu.com/MultiarchSpec> for details.
The asm subdirectory isn't in $Config{usrinc} anymore: /usr/include/asm
is now /usr/include/x86_64-linux-gnu/asm. (The third component of the
new path varies with the actual architecture.)
gcc --print-search-dirs doesn't really tell anything about where gcc
looks for the include directories, it was just used to find the gcc
internal directory prefix.
Parse the output of "gcc -v -E" instead, and append $Config{usrinc}
for safety. Duplicates shouldn't matter.
The h2ph "-a" switch isn't currently tested automatically, and that
seems nontrivial to do portably. Manual testing was done with
# mkdir ttt
# ./perl -Ilib ./utils/h2ph -a -d $(pwd)/ttt syscall.h
The gcc invocation has been tested to work with gcc 4.6, 4.1, and 3.3.
http://bugs.debian.org/625808
https://bugs.launchpad.net/bugs/777903
|
| | |
|
| |
|
|
|
|
|
| |
The duplicated code could have had no effect - for the case of pos <= 0
pp_study had already returned NO. The second call to SvPV() would have had no
side effects, because scalars with side effects don't have SvPOK() true, so
would also have already returned NO.
|
| | |
|
| |
|
|
| |
This removes duplication of open_new() calls.
|
| |
|
|
| |
Use this in embed.pl for perlapi.c, and reentr.pl for reentr.c.
|
| |
|
|
| |
Merge together many calls to open_new() and read_only_top().
|
| |
|
|
|
| |
This eliminates the only remaining external caller of read_only_bottom(), so
inline read_only_bottom() into read_only_bottom_close_and_rename().
|
| |
|
|
| |
Inline safer_rename() into its only caller, close_and_rename().
|
| |
|
|
| |
Use this in regen/uconfig_h.pl
|
| |
|
|
| |
Update the SHA256s where necessary in the generated files.
|
