The IntStructPtrMap and IntStructConstPtrMap sections passed newly
constructed Struct objects straight into the map and kept no Lua
reference to them. These maps store just the raw pointers, so once the
incremental collector completed a cycle the Struct objects were deleted
and the maps were left holding dangling pointers. The following value
checks then read freed memory, which sporadically failed in CI with:
li_std_map_runme.lua:68: ispmap:get(8)
Hold the Struct objects in a Lua table for the lifetime of the maps.
Confirmed as a use-after-free with valgrind and reproducible before the
fix by lowering the collector pause with collectgarbage("setpause", 105).
Assisted-by: Claude Code (Opus 5)
A character constant containing more than one character, e.g. 'ab', has
type int per both the C standard (6.4.4.4p10) and the C++ standard
([lex.ccon], which describes it as a "multicharacter literal"). SWIG
previously classified every character constant as char regardless of
length, which caused the generated wrapper accessor for a constant such
as #define X 'ab' to be declared char instead of int, silently
truncating the value.
The literal text is left untouched (SWIG does not evaluate constant
expressions), only the internal type tag changes, so the real compiler
that builds the generated wrapper still computes the (implementation
defined) value, exactly as it would for hand written C/C++ code.
Add a new C-only multichar_constant.i test case with per-language runme
files, and keep the new csharp/java char_constant runme files (which
had no coverage before) for the existing, unrelated character constant
checks.
Compiling a real multicharacter constant always triggers GCC's
-Wmultichar warning. #pragma GCC diagnostic ignored "-Wmultichar" does
not suppress it: this is a known, longstanding GCC C++ front-end bug
(gcc.gnu.org PR57241/PR53431, fixed in GCC 13) - verified locally that
it fails identically on GCC 11 and 12 regardless of file- or
function-level pragma scope, while working fine in C or with GCC 13+
or Clang (which also defines __GNUC__ but doesn't have this bug).
The new testcase avoids the warning entirely, with no build system
changes needed:
- The %inline global variable imulti_ab uses the real literal (guarded
by the pragma) wherever that's known to work, and otherwise falls
back to reconstructing the identical value GCC's own packing of
'ab' produces (most significant byte first) without writing a
multicharacter literal at all - the same symbol name and type either
way, so the generated accessor links correctly regardless of which
branch was compiled.
- The #define-driven MULTICHAR_AB constant (whose registration code is
auto-generated per target language, so a similar fallback isn't
portable to hand-write once for every language) is skipped entirely
for octave and javascript's node/napi/v8 engines, the only
configurations that always compile the generated wrapper as C++
regardless of SWIG's own -c/-c++ mode (their runtime APIs require
it) and so would otherwise still hit the GCC bug above.
Verified against both GCC 13 (default) and GCC 11 (matching the actual
CI toolchain that originally failed) across all configured languages.
Assisted-by: Claude Code (Sonnet 5)
R::enumvalueDeclaration built the enum item label passed to
defineEnumeration from the C++ name rather than sym:name, so %rename of an
enum item was not honoured in the generated R code. Use sym:name for the
label.
Add test coverage for %rename of an enum class and an enum item to the
cpp11_strongly_typed_enumerations runme of every target language that has
one, locking in the behaviour for the languages that were already correct.
The enum_thorough R runme now checks the renamed enum item too.
Assisted-by: Claude Code (Opus 4.8)
the new Lua directors feature uses lua_setuservalue, added in Lua 5.2.
Removing the LUA_VERSION_NUM-guarded compatibility defines for lua_rawlen,
lua_pushglobaltable and lua_rawsetp/lua_rawgetp from Lib/lua/luarun.swg.
LuaJIT implements the Lua 5.1 API and, per its own documentation, is
"API+ABI-compatible with Lua 5.1, which prevents implementing features
that would otherwise break the Lua/C API and ABI" (https://luajit.org/extensions.html,
"Extensions from Lua 5.2" section) - so it never defines these Lua 5.2 additions.
Noticed when rebuilding obs-studio's LuaJIT-based Lua bindings against SWIG master.
Restore those compatibility defines, scoped to 5.1 and later only (the old
Lua 5.0-only shims are not restored).
Also revert an incidental ok!=LUA_OK comparison introduced by #3394
back to ok!=0, since LUA_OK isn't defined pre-5.2 either and luaL_dostring()
already returns 0 on success on every Lua version.
Fix the examples and test-suite where they themselves used Lua 5.2 only
features: LUA_OK in Examples/lua/embed/embed.c, _ENV in helpers.lua, and
string.format("%c", ...) in li_cdata_bytes, which yields an empty string for a
NUL byte in Lua 5.1 as strlen() is applied to the formatted result, so
string.char() is used instead.
Directors continue to require Lua 5.2 or later and are unaffected by this
change; the Lua 5.1 director test failures are addressed separately.
Assisted-by: Claude Code (Sonnet 5)
Reported on the swig-devel mailing list during early testing of swig-4.5,
where CrossWire SWORD's Perl bindings (GBFHTMLHREF::MyUserData deriving
from BasicFilterUserData) failed to build: a protected or private nested
class deriving from a class used elsewhere in the wrapped API could produce
a runtime upcast helper function referencing the nested class by its
inaccessible qualified name, a C++ compile error. No target language ever
wraps a non-public nested class, so typepass.cxx now simply skips
registering it for the cast table. Fixes it for Lua too, which hits the
same bug as Perl/Python/Ruby/Tcl despite having full nested class support,
since Java/C# are structurally immune (they don't use SWIG's generic
runtime type table at all). Added regression tests to nested_scope.i and
director_protected.i (covering directors/dirprot), with a runtime check in
every director_protected runme confirming polymorphic dispatch through the
wrapped base still works correctly.
Assisted-by: Claude Code (Sonnet 5)
A 'char *&' (a reference to a char pointer) was only marshalled as a string by
C#, D, Go, Java and PHP; every other language treated it as an opaque char **
pointer. Add char *& string typemaps to the languages that were missing them,
so a char *& function argument, return value or variable is marshalled as a
string in every target language. SWIG's const reference stripping means this
also covers char *const&.
- Lib/typemaps/strings.swg: add Char *& to the %typemaps_string in, freearg,
out, typecheck and director typemaps. This gives char *& to the languages
that use the Unified Typemap Library (Python, Ruby, Perl, Tcl, Octave, Scilab,
R and JavaScript). The shared in typemap now casts &buf to $1_ltype so that a
const char * reference hidden behind a typedef also compiles.
- Lib/lua/luatypemaps.swg, Lib/guile/typemaps.i, Lib/ocaml/ocaml.swg: these
define their own char * string typemaps; give each char *& and const char *&
in/out/freearg typemaps too.
- Lib/r/rtype.swg: the C wrapper returned the char *& string correctly but the R
proxy wrapped it as an undefined _p_p_char S4 class; add char *& to the
scoerceout char list so it is returned as a plain character value.
char_strings.i is now exercised by a runme in every target language, all testing
the same set of functions (get/set/pingpong/global variables and all four char *&
functions), giving complete char *& typemap coverage and testing.
Where a language genuinely cannot support part of the char array portion of the
test (a char[] global has no varin typemap in most scripting languages, a char[16]
parameter is bounds checked, and Guile/OCaml reject char[] parameters), that one
assertion is adapted or skipped with an inline comment; the char *& coverage is
complete everywhere.
Assisted-by: Claude Code (Opus 4.8)
The Go 'in' typemap for char * wrote the null terminator through $1, which
fails to compile as C++ when the matched type is const char *, as happens
with a typedef such as 'typedef const char *MyString'. Allocate and write
the terminator through a char * temp, assign to $1 via $1_ltype, and cast
in the freearg so a const char * buffer can still be freed. Freeing $1
(rather than the temp) keeps the freearg working when char * is remapped
with %apply SWIGTYPE[], which overrides the in typemap but not the freearg.
Add coverage to the common char_strings.i test, which is compiled for
every language, rather than a Go only test: a typedef'd const char * setter
plus a runtime assertion in each language that has a char_strings runme
(c, csharp, d, java, javascript, lua, perl5, php).
See #3290.
Assisted-by: Claude Code (Opus 4.8)
And move it to helpers.
Although Lua uses C floating math.
The actual used C floating functions in Lua
might be different from the actual floating functions
used in the original C code, which may lead to a slightly
different floating number.
So for calculated floating numbers we should use the cmp_flt function in the assert.
Signed-off-by: Erez Geva <ErezGeva2@gmail.com>
For some target languages (Octave, Python and Ruby), SWIG has previously
treated nullptr or NULL as an integer 0 if used in a situation where
the type wasn't known to be a pointer.
For nullptr this is never helpful, because it has type nullptr_t which
does not implicitly convert to 0, so we no longer do this.
For NULL it's rather dubious - C and C++ allow NULL to be defined as
integer 0, so `int i = NULL` may work and is occassionally seen in real
code, but it is semantically wrong. Also GCC and clang define NULL to a
magic value and by default will warn about such misuse, so it's likely
to be less common than before they did this. So now SWIG only converts
NULL to 0 if used in a context where we know the underlying type is an
arithmetic type.
Using an integer zero (or equivalent value such as 0L) for a NULL
pointer is valid, and SWIG will still treat it as a NULL pointer if used
in a context where know the type is a pointer. This is now done based
on the value of the integer constant so also applies to 0L (previously
it was only done if the value was written in the code as literally `0`).
Fixes: #3472
C++11 inheriting constructors (using Base::Base;) now work when the immediate
base class is named through a typedef, a chain of typedefs, a typedef whose
template argument is itself a typedef, a scope-qualified or namespaced name, or
a type-template parameter used directly as the base class (the mixin idiom).
The inheriting constructor's using-declaration qualifier is normalized in the
typepass stage; the inheriting base is then found by identity in the resolved base
class list and the base class' constructors are used to implement the inherited
constructors.
An inheriting-constructor using declaration whose qualifier is not an immediate
base class is reported with Warning 329 (uses base '...' which is not an
immediate base of '...') rather than the generic Warning 315.
Closes#2951)
Assisted-by: Claude Opus 4.8
When a base class declares a constructor of its own, the constructor shares the
base class name. Resolving a typedef that names the base to its scope looked the
base class name up through the derived class' inherited scope and found the base
constructor ahead of the class itself, so no typedef scope alias was created and a
later 'using base_type::member;' was reported as Warning 315 and the member
silently dropped.
Skip constructor nodes (including the using-declaration nodes that inherit base
constructors, which also carry the class name) when resolving a typedef to its
scope, so the class node is found instead.
Resolving the typedef now goes through Swig_symbol_clookup_check, whose
using-declaration chase loop was missing the self-reference guard that
Swig_symbol_clookup already has. Add it to avoid infinite recursion (a stack
overflow and crash) on a self-referential using declaration; the existing test
Examples/test-suite/using2.i, with a top-level 'using ::baz;', exercises this.
Assisted-by: Claude Opus 4.8 (1M context)
- Add Lua examples
- Add and fix unused Lua tests
- Add lua_module_global complementary test of lua_no_module_global
- Add Lua test-suite runme files
Enable friends_nested and minherit inline test code for Lua via the
SWIGLUA guards.
- lua.cxx: clarify old_compatible_names comment; the flag is no longer user-controllable.
- director_enum_runme.lua: restore catch_undef_globs() lost in the import.lua rewrite.
- cpp17_string_view_runme.lua: drop redundant require_to_globs return-value capture.
Assisted-by: Claude Opus 4.7
- configure.ac
- Use minimum version 5.2 for Lua
- Add lua 5.5, it was released in dec 2025
- Syntax improvements
- GHA CI
- Remove 'default' Lua version, it is confusing.
Just select the version explicitly.
- Add Lua 5.4 test, we need to test all supported versions 5.2, 5.3 and 5.4
Lua 5.5 is not available on Ubuntu yet.
- Lua documentation Doc/Manual/Lua.html
- Update version to 5.2
- Remove mention to older SWIG version,
whom wishes to go to the very old history can look on CHANGES.
- Add references on missing operators in Lua.
- _ENV exist from Lua 5.2.
- Remove old compatibility code from Lib/lua/luarun.swg.
- Remove LUA_VERSION_NUM from Lua C wrapping code.
It was used for old Lua 5.0 and Lua 5.1.
- Remove _VERSION from Lua tests.
Note: _VERSION remains a keyword and developers may use it in interface files!
- Remove Example/lua/import.lua and Examples/test-suite/lua/import.lua
as they are not used or needed any longer.
- Remove old Lua import.
- Add Examples/test-suite/lua/helpers.lua
- include it in all tests in test-suite.
- Add catch "undefined" global variables enable function.
- Add import_to_globs function.
To add module functions, variables and classes to global scope.
- Remove the -squash-bases option as it is broken
The der.new_func from the example
in the document, "29.3.18.3 Inheritance",
pass from base object to derived object
regardless of using the flag or not.
- Remove -no-old-metatable-bindings as it is deprecated in the last 12 years
Signed-off-by: Erez Geva <ErezGeva2@gmail.com>
The cdata.i (const void *BYTES, size_t LENGTH) typemap took LENGTH from
SWIG_AsCharPtrAndSize, whose psize includes a trailing NUL (data length
+ 1). When the destination buffer is sized exactly to the data, memmove
wrote one byte past the end. Confirmed with valgrind: "Invalid write of
size 1, 0 bytes after a block of size 512".
- Make SWIG_AsCharPtrAndSize binary aware in the languages that use the
generic Lib/cdata.i (Python, Perl, Ruby, Octave, R): when the caller
passes SWIG_BINARYSTR it now reports the exact byte count, not data
+ 1. Non cdata callers are unaffected as they never set the flag.
- Lua li_cdata_bytes tests looped to 0x99 instead of 0xff, verifying
only 154 of the 256 byte values; corrected to 0xff.
- Tcl cdata.i passed an int * to Tcl_GetSizeIntFromObj, which expects
a Tcl_Size * on Tcl 8.7 and 9; use Tcl_Size and reject values that
are not a byte.
- CHANGES.current: document the cdata type change and the overflow fix.
Assisted-by: Claude Opus 4.7
Fix guile cdata.
Add SWIG_BINSTR flag
- Add SWIG_FromBinCharPtrAndSize with the new flag
To add languages that use Lib/cdata.i.
- python use binary string by using the new SWIG_BINSTR
in SWIG_AsCharPtrAndSize and SWIG_FromBinCharPtrAndSize.
Languages that were changed to uses list
- Tcl use list of integers.
- scilab use list of uint8.
And support passing list of numbers to C.
Add support to JavaScript
- use Uint8Array instead of strings.
- Add li_cdata_carrays. tests.
- Add li_cdata_bytes tests.
- Use Debian node-addon-api package location.
- napi folder location to Examples/test-suite/javascript/Makefile.in.
- Update documentation.
Update cdata.i documentation
This new cdata test focus on:
- Ensure we can receive proper data from C and pass proper data back to C.
- Use all possoble byte values , i.e. the full range of 0 to 255
and ensure values 128 to 255 do not pass Unicode transformation (UTF-8/16).
- Ensure zero is a valid value and not a string null termination
nor a modified UTF-8 which transform U+0000 to 0xC0 0x80.
- Check mutability of the cdata object.
Signed-off-by: Erez Geva <ErezGeva2@gmail.com>
When using D, JavaScript, Lua, PHP, R
Perhaps some better language specific uses of %namewarn/%keywordwarn
for keyword handling could instead be implemented??
- Add changes entry for new Lua shared_ptr support.
- Rename director_smartptr test to director_shared_ptr.
- Reimplement cpp11_shared_ptr test cases so that they are run by all
languages (in common.mk instead of being in chosen language's Makefile.in files).
This makes sure missing tests are run by all languages that support
shared_ptr.
* Add a minimal director test
The purpose of this test is to provide
the minimal test the prove a language
support the director feature.
The test does not replace any of the other director tests.
But merely a starting point.
* alphabetical order fix
Signed-off-by: Erez Geva <ErezGeva2@gmail.com>
Co-authored-by: William S Fulton <wsf@fultondesigns.co.uk>
Most languages now use "NullReferenceError" in the error message
where they previously used "ValueError". Also exception changes:
Guile: "swig-null-reference-error" instead of "swig-value-error"
MzScheme: "swig-null-reference-error" instead of "swig-value-error"
PHP: zend_ce_type_error instead of zend_ce_value_error
Python: Consistently raises TypeError instead of a mix of ValueError
and TypeError.
Ruby: Consistently raises NullReferenceError instead of a mix of
ArgumentError and NullReferenceErrorError.
The consistent raising of a TypeError instead of ValueError for Python
ensures that incorrectly passing 'None' into a C++ reference argument
will correctly convert the error into a NotImplemented error for
the rich comparisons implementations per PEP 207. Fixes#2987
Note that the li_constraints checking implementation for the NONNULL
typemap for pointers also makes the same error change from
SWIG_ValueError to SWIG_NullReferenceError.
The D typemaps use SWIG_DNullReferenceException instead of
SWIG_DIllegalArgumentException, although this ultimately has no change
as the same D Exception is still thrown.
* char_binary_java_fix-tidyup:
Move SWIGStringWithLengthHelper to csharphead.swg
cdata whitespace/cosmetic fixups
cdata doc updates
Rename `typemaps/cdata_struct.swg` to `typemaps/cdata_begin.swg`. And `typemaps/cdata.swg` to `typemaps/cdata.swg`. Move `cdata_apply.swg` content to `typemaps/cdata.swg`.
Group the C# marshalling of STRING-LENGTH typemap into C# class named SWIGStringWithLengthHelper.
Leave Length & string reverse order typemap in typemaps/strings.swg
Support old C# as "LPUTF8Str" was add in 2017.
Improve documentation. Follow @wsfulton reviews.
Use a dummy for MzScheme and untested OCaml cdate. To prevent compilation error.
Further fixing follow reviews.
Reorganise raw data typemap, so typemaps folder contain only common part. Improve document.
Inline SWIG_string_to_utf8_bytes SWIG_utf8_bytes_to_string code
Fixes of STRING/BYTES LENGTH typemaps.
Conflicts:
CHANGES.current
Java's nested iterator class in std::map, std::set, std::unordered_map,
std::unordered_set needs to be public instead of protected for
access to work when moving STL types into different Java packages.
For example:
%nspace Space::OuterClass80;
namespace Space {
struct OuterClass80 {
struct InnerClass80 {
struct BottomClass80 {};
};
enum InnerEnum80 { ie80a, ie80b };
};
}
Previously the following were additionally required for some languages:
%nspace Space::OuterClass80::InnerClass80;
%nspace Space::OuterClass80::InnerClass80::Bottom80;
Now the appropriate nspace setting is taken from the outer class.
A new warning has also been introduced to check and correct conflicting
nspace usage, for example if the following is additionally added:
%nspacemove(AnotherSpace) Space::OuterClass80::InnerClass80;
The following warning appears as an inner class can't be moved outside
of the outer class:
Warning 406: Ignoring nspace setting (AnotherSpace) for 'Space::OuterClass80::InnerClass80',
Warning 406: as it conflicts with the nspace setting (Space) for outer class 'Space::OuterClass80'.
This really helps with %nspacemove as now one can simply move an outer
class to another namespace, like this:
%nspacemove(AnotherSpace) Space::OuterClass80;
and all the nested classes will automatically also be moved
into the appropriate namespace.
%nspacemove moves a class or enum into a different target language 'namespace'.
This builds on top of %nspace and so is currently only implemented in
C#, D, Java, Javascript and Lua.
Javascript also supports %nspace for functions and variables in a
namespace with a non-standard implementation; %nspacemove is not
fully working yet for Javascript.
Issue #2782
instead of copy constructor when passing movable types. This was
previously implemented only for parameters passed to a global function
or static member function and is now extended to member methods.
Enhancement to e777b054d5.
Fix Java STRING LENGTH typemap.
Use string type in static typed languages (Java, C#, D and Go).
Add BYTES LENGTH typemap and apply it for binary data.
Use byte type in static typed languages.
Add li_cdata_cpp, li_cdata and char_binary
tests for most of languages(apart from R and experimental).
Fix the director_binary_string test and add it to C#, D, Go,
Perl, PHP, Python, Ruby and octave.
Update documents.
Signed-off-by: Erez Geva <ErezGeva2@gmail.com>
Order of evaluation of C++ function arguments is not defined, and if
lua_rawlen() was called before lua_tostring() then it would return 0
(because the value was still a number) and an empty string would be
passed.
The same issue affects std::string_view too, but that's not been in
a release yet.
The new testcases fail without the fix with GCC 12.2 on x86-64 Linux.
William S Fulton