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
This OS has been unsupported for over 20 years. We stopped providing
macswig builds more than 20 years ago too:
https://sourceforge.net/projects/swig/files/macswig/
The required SIOUX library doesn't seem to be available anywhere
now either.
Closes#2323
Avoid using reserved identifiers such as `_DOHINT_H` (fixes#1989),
fix cases where the name doesn't match the filename, and make the naming
more consistent and less likely to collide with include guards in other
headers.
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
It seems too brittle to enable by default as we'd have to avoid
including any system headers after doh.h, which is hard to enforce,
but just having it enabled for one CI job should avoid uses of the
poisoned symbols from being accidentally introduced.
See #2223
Use `#pragma GCC poison` (supported since GCC 3, maybe earlier) when
compiling with GCC to help prevent direct uses being introduced for
functions which DOH provides a wrapper for.
Exit() is a wrapper for exit() by default, but SetExitHandler() allows
specifying a function to call instead.
This means that failures within DOH (e.g. Malloc() failing due to lack
of memory) will now perform cleanup such as removing output files.
This commit also cleans up exit statuses so SWIG should now reliably
exit with status 0 if the run was successful and status 1 if there was
an error (or a warning and -Werror was in effect).
Previously in some situations SWIG would try to exit with the status set
to the number of errors encountered, but that's problematic - for
example if there were 256 errors this would result in exit status 0 on
most platforms. Also some error statuses have special meanings e.g.
those defined by <sysexits.h>.
Also SWIG/Javascript tried to exit with status -1 in a few places (which
typically results in exit status 255).
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.
For example, `Char(foo)[0]` now works to get the first character
of DOH String `foo`.
Previously this gave a confusing error because it expanded to
`(char *) Data(foo)[0]` and the `[0]` binds more tightly
than the `(char *)`.
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
Previously generated files were not removed,
potentially breaking Makefiles using file dependencies, especially when
-Werror (warnings as errors) was used.
The commit 40bf877 fixed warnings about converting between function and object
pointers but introduced warnings about breaking strict-aliasing rules which
appear with -Wstrict-aliasing which is implicitly enabled by -O2.
Avoid these warnings as well by using an intermediate union for conversion
instead of casts trickery.
Work around harmless (at least under POSIX systems where function pointers are
guaranteed to have the same representation as object pointers) but annoying
warnings given by gcc when converting between function and object pointers, e.g.
Source/DOH/fio.c: In function 'DohEncoding':
Source/DOH/fio.c:51: warning: ISO C forbids conversion of function pointer to object pointer type
Source/DOH/fio.c: In function 'encode':
Source/DOH/fio.c:75: warning: ISO C forbids conversion of object pointer to function pointer type
Source/DOH/base.c: In function 'DohCall':
Source/DOH/base.c:952: warning: ISO C forbids conversion of object pointer to function pointer type
Use an extra level of pointer indirection to avoid them.
