The one we're currently using only considers the last five characters
plus the least significant bit of the last-but-sixth character, which
unsurprisingly generates a lot of many-way collisions.
This change seems to give about a 4% reduction in wallclock time for
processing li_std_list_wrap.i from the testsuite for Python. The
hash collision rate for this example drops from 39% to 0!
Closes#2303
Changing the hash function breaks some testcases.
It seems there's a latent bug here (I suspect something somewhere in
SWIG depends on the hash iteration order), but I didn't see where and
we can't really have CI continuing to fail.
See #2303.
This reverts commit 5a96a39aa4.
The one we're currently using only considers the last five characters
plus the least significant bit of the last-but-sixth character, which
unsurprisingly generates a lot of many-way collisions.
This change seems to give about a 4% reduction in wallclock time for
processing li_std_list_wrap.i from the testsuite for Python. The
hash collision rate for this example drops from 39% to 0!
Closes#2303
With flags DOH_REPLACE_ID_BEGIN, DOH_REPLACE_ID_END and
DOH_REPLACE_NUMBER_END the code looked for a match for the token
string using strstr() and then checked the extra condition - if the
extra condition didn't apply it then advanced by the length of the token
before searching again.
However that can miss matches if the strstr() matches can overlap
one another, so only advance one position, which is conservative
but can't miss matches.
For example this would not match before:
Replace("123123", "1231", r, DOH_REPLACE_NUMBER_END);
This issue seems to be entirely latent in the current SWIG codebase
due to the nature of the token strings passed when using these flags.
See #2235
Previously code in the SWIG tool didn't handle allocation failures
well. Most places didn't check for NULL return from
malloc()/realloc()/calloc() at all, typically resulting in undefined
behaviour, and some places used assert() to check for a NULL return
(which is a misuse of assert() and such checks disappear if built with
NDEBUG defined leaving us back with undefined behaviour).
All C allocations are now done via wrapper functions (Malloc(),
Realloc() and Calloc()) which emit and error and exit with non-zero
status on failure, so a non-NULL return can be relied upon.
Fixes#1901.
If the source and replacement strings were the same length, the code
was performing undefined pointer arithmetic involving a NULL pointer.
I'm not aware of any observable effects of this in practice, but it's
potentially problematic. It's detected by ubsan, for example when
running `make check-python-test-suite`:
DOH/string.c:839:4: runtime error: applying non-zero offset to non-null pointer 0x602000001558 produced null pointer
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior DOH/string.c:839:4 in
- Add support to DOH Replace for not replacing inside C comments
- Fix removing 'out' or 'ref' when these are present in C comments
in cstype typemaps.
Closes#1628
Writing a buffer to a DOH object doesn't modify so it should be const.
This allows the code using const pointers to pass them to DohWrite() without
neither the casts nor gcc warnings.
git-svn-id: https://swig.svn.sourceforge.net/svnroot/swig/trunk@12167 626c5289-ae23-0410-ae9c-e8d60b6d4f22
