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.
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
https://swig.svn.sourceforge.net/svnroot/swig/branches/swig-2.0
........
r11085 | bhy | 2009-01-25 00:21:55 +0800 (Sun, 25 Jan 2009) | 2 lines
Fix const-correctness.
........
r11086 | bhy | 2009-01-25 02:08:50 +0800 (Sun, 25 Jan 2009) | 2 lines
Correct some function definition in header files, which implementation changed in previous commit caused mismatch.
........
r11088 | bhy | 2009-01-25 02:38:32 +0800 (Sun, 25 Jan 2009) | 1 line
minor fix and now SWIG is alive again
........
r11089 | bhy | 2009-01-25 06:07:07 +0800 (Sun, 25 Jan 2009) | 1 line
Correct some bug introduced in previous commits. Now SWIG is pretty good with C++ compiler.
........
git-svn-id: https://swig.svn.sourceforge.net/svnroot/swig/trunk@11097 626c5289-ae23-0410-ae9c-e8d60b6d4f22
