swig-devel — SWIG Developer List

Re: [Swig-devel] Proposal: add an option to forbid using descriptors in output

[William S F. <ws...@fu...>]

On Tue, 9 Sept 2025 at 22:09, Vadim Zeitlin <vz...@ze...> wrote:

> On Tue, 9 Sep 2025 14:45:46 +0100 William S Fulton <
> ws...@fu...> wrote:
>
> WSF> Yes, very welcome. I have taken the same approach too and fail the
> build if
> WSF> some SWIGTYPE_xxx.java or SWIGTYPE_xxx.cs files are generated. But
> clearly
> WSF> this only works if wrappers include one of java or C# target
> languages so
> WSF> is somewhat limited.
>
>  Yes, exactly.
>
> WSF> Would be nice to have it in the warning system to selectively
> suppress/add
> WSF> warnings for certain types. The warning system is already very
> powerful
> WSF> with selective suppressions and hidings and turning into errors. The
> WSF> problem is the best part of the warning system flexibility works off
> types
> WSF> that have been parsed, so becomes a catch 22 in this instance given
> the
> WSF> idea is to warn about unknown types. I'll have a think and get back.
>
>  I was thinking about a global warning (I think there are already some,
> aren't there?) because I indeed don't see any way to attach a warning to
> unknown types. If we do agree to implement this as a warning, I'd like to
> know if you prefer it to be enabled or disabled by default




>  If we decide to implement this as a new option, it would be somewhat
> simpler as it would, of course, be off by default and would result in an
> error if this new option is used and an unknown type is encountered.
>
>
>
Okay, let's try as a new global warning, off by default. Off by default
will require adding it to the list of the extra warnings:

$ swig -help | grep Wextra
     -Wall           - Remove all warning suppression, also implies -Wextra
     -Wextra         - Adds the following additional warnings:
309,403,405,512,321,322

Unfortunately there are a number of other unknown type related warnings
that would be nice to suppress by naming the unknown type in %warnfilter,
but this could be tackled at a later stage as a general enhancement to
suppressing unknown type related warnings. I suspect your implementation of
the new warning would be a step in that direction as the unknown types,
once detected, could be added into an unknown types list. BTW, which stage
of parsing do you intend to add the code to add in the new warning?

(but I'd also
> like to add an option to make selected warnings into errors in any case, as
> I already wrote).


A user, after turning on the new warning, could use the normal warning /
error machinery to turn the new warning into an error by adding -Werror.
This does of course require a warning free code base in the first place as
you point out, SWIG does have a way to treat specific warnings as errors.
For this we'd need to implement the equivalent to gcc's -Werror= option. I
think this needs a bit of design and thought, such enhancing #pragma to do
the same. I don't intimately know all the gcc warning flag options, but
they probably should be thoroughly examined for inspiration. Thinking of
what would additionally would be documented in Warnings.html could make up
a proposal.

William

Re: [Swig-devel] Proposal: add an option to forbid using descriptors in output

[Vadim Z. <vz...@ze...>]

On Tue, 9 Sep 2025 14:45:46 +0100 William S Fulton <ws...@fu...> wrote:

WSF> Yes, very welcome. I have taken the same approach too and fail the build if
WSF> some SWIGTYPE_xxx.java or SWIGTYPE_xxx.cs files are generated. But clearly
WSF> this only works if wrappers include one of java or C# target languages so
WSF> is somewhat limited.

 Yes, exactly.

WSF> Would be nice to have it in the warning system to selectively suppress/add
WSF> warnings for certain types. The warning system is already very powerful
WSF> with selective suppressions and hidings and turning into errors. The
WSF> problem is the best part of the warning system flexibility works off types
WSF> that have been parsed, so becomes a catch 22 in this instance given the
WSF> idea is to warn about unknown types. I'll have a think and get back.

 I was thinking about a global warning (I think there are already some,
aren't there?) because I indeed don't see any way to attach a warning to
unknown types. If we do agree to implement this as a warning, I'd like to
know if you prefer it to be enabled or disabled by default (but I'd also
like to add an option to make selected warnings into errors in any case, as
I already wrote).

 If we decide to implement this as a new option, it would be somewhat
simpler as it would, of course, be off by default and would result in an
error if this new option is used and an unknown type is encountered.

 But I'll wait to see if you have any better ideas.

 Thanks in advance!
VZ

Re: [Swig-devel] Proposal: add an option to forbid using descriptors in output

[William S F. <ws...@fu...>]

Yes, very welcome. I have taken the same approach too and fail the build if
some SWIGTYPE_xxx.java or SWIGTYPE_xxx.cs files are generated. But clearly
this only works if wrappers include one of java or C# target languages so
is somewhat limited.

Would be nice to have it in the warning system to selectively suppress/add
warnings for certain types. The warning system is already very powerful
with selective suppressions and hidings and turning into errors. The
problem is the best part of the warning system flexibility works off types
that have been parsed, so becomes a catch 22 in this instance given the
idea is to warn about unknown types. I'll have a think and get back.

William

On Sat, 6 Sept 2025 at 21:18, Vadim Zeitlin <vz...@ze...> wrote:

>  Hello,
>
>  Whenever I use SWIG I find myself adding a post-compile step which checks
> that no types have been wrapped as "opaque types" using SWIGTYPE_p_xxx
> names because I never want this to happen and it always indicates some
> error in my .i file.
>
>  And while doing it in a separate build step is not that difficult, it's
> still an extra thing to do and so I'd like to propose adding an option
> ("-nounknown"?) which would exit with an error if SWIG detects any such
> types. Alternatively, we could add a warning instead, but this warning
> would probably need to be disabled by default and I'd also like to add a
> possibility to turn just the specified warning into an error then (e.g.
> "-w!599" or something like this).
>
>  Would a PR implementing a new option or a new warning be welcome?
>
>  Thanks in advance for your thoughts,
> VZ
> _______________________________________________
> Swig-devel mailing list
> Swi...@li...
> https://lists.sourceforge.net/lists/listinfo/swig-devel
>

[Swig-devel] Proposal: add an option to forbid using descriptors in output

[Vadim Z. <vz...@ze...>]

 Hello,

 Whenever I use SWIG I find myself adding a post-compile step which checks
that no types have been wrapped as "opaque types" using SWIGTYPE_p_xxx
names because I never want this to happen and it always indicates some
error in my .i file.

 And while doing it in a separate build step is not that difficult, it's
still an extra thing to do and so I'd like to propose adding an option
("-nounknown"?) which would exit with an error if SWIG detects any such
types. Alternatively, we could add a warning instead, but this warning
would probably need to be disabled by default and I'd also like to add a
possibility to turn just the specified warning into an error then (e.g.
"-w!599" or something like this).

 Would a PR implementing a new option or a new warning be welcome?

 Thanks in advance for your thoughts,
VZ

Re: [Swig-devel] swig-4.4 release dates

[Jitka P. <jpl...@re...>]

On 9/4/25 23:11, Olly Betts wrote:
> Some I can answer.  Probably useful to open issues for anything we can't
> easily sort out here.
Thank you for the quick response. I've created pull requests with fixes 
for libCombine and pyscard. I will create issues for the remaining 
errors. Regards, Jitka
> On Thu, Sep 04, 2025 at 11:46:07AM +0200, Jitka Plesnikova via Swig-devel wrote:
>> ### libCombine
>>
>> /builddir/build/BUILD/libCombine-0.2.20-build/libCombine-0.2.20/redhat-linux-build/src/bindings/python/libcombine_wrap.cpp:7858:7: error: ?$function? was not declared in this scope; did you mean ?PyCFunction??
>>   7858 |       $function
>>        |       ^~~~~~~~~
>>        |       PyCFunction
> Finally removed having been deprecated since 2008; replace with $action
> (search for $funtion in CHANGES.current).
>
>> ### pyscard
>>
>>    src/smartcard/scard/scard_wrap.c: In function ?_wrap_SCardAddReaderToGroup?:
>>    src/smartcard/scard/scard_wrap.c:4534:5: error: unknown type name ?$function?; did you mean ?PyCFunction??
>>     4534 |     $function
>>          |     ^~~~~~~~~
>>          |     PyCFunction
> Ditto.
>
>> ### subversion
>>
>> subversion/bindings/swig/python/svn_client.c: In function '_wrap_svn_client_get_simple_prompt_provider':
>> subversion/bindings/swig/python/svn_client.c:4259:7: error: implicit declaration of function 'SWIG_Python_TypeError'; did you mean 'SWIG_Python_TypeQuery'? [-Wimplicit-function-declaration]
>>   4259 |       SWIG_Python_TypeError(SWIG_TypePrettyName(SWIGTYPE_p_apr_pool_t), obj2);
>>        |       ^~~~~~~~~~~~~~~~~~~~~
>>        |       SWIG_Python_TypeQuery
> Removed in 9c2a1bc39c43dfe8958af36a5168412c67b467a9 as "not used".  Not
> sure what the replacement in user typemaps would be.  We probably should
> note this removal in CHANGES.current along with a suggestion for how to
> deal with such uses.  William?
>
>> ### unbound
>>
>> libunbound/python/libunbound_wrap.c: In function '_wrap_ub_resolve':
>> libunbound/python/libunbound_wrap.c:5889:3: error: unknown type name '$function'; did you mean 'PyCFunction'?
>>   5889 |   $function
>>        |   ^~~~~~~~~
>>        |   PyCFunction
> Ditto.
>
> Cheers,
>      Olly
>

-- 
Jitka Plesnikova
Senior Software Engineer
Red Hat

Re: [Swig-devel] swig-4.4 release dates

[Jitka P. <jpl...@re...>]

Hi,

I ran scratch rebuild of SWIG dependencies that we had in Fedora.

For comparison, I ran a rebuild against SWIG 4.3.0, which we have in
Fedora, and against SWIG 4.4.0 from commit b440f9eeb.

You can see difference between builds here:
* swig 4.3.0
https://copr.fedorainfracloud.org/coprs/jplesnik/swig-rebuild/monitor/
* swig 4.4.0
https://copr.fedorainfracloud.org/coprs/jplesnik/swig-test/monitor/

There are some packages that are failing only with the new version:
* libCombine
* nordugrid-arc
* plplot
* pygsl
* pyscard
* subversion
* unbound

The errors causing these failures are in the attached file for each
package.

The complete build logs can be found here:
https://jplesnik.fedorapeople.org/swig44/

Could you please help me find a fix for these?

Should I create tickets for them?

Regards,
Jitka


On 8/29/25 09:02, William S Fulton wrote:
> I would like to release swig-4.4 during September prior to the 
> python-3.14 release. The SWIG release is overdue now with the target 
> date set on the milestone https://github.com/swig/swig/milestone/10. I 
> don't think I can contribute much to any of the issues on the 
> milestone, except maybe taking over #3189 #3192 if that helps you 
> Olly. Olly, are any of these others a blocker and doable by you? Can 
> we aim for something like 28 Sep? If not let's bump them off the list.
>
> Otherwise my plan is to work on getting python -builtin to work with 
> the limited API if nothing else gets in the way.
>
> Please add any essential tickets to the milestone.
>
> William
>
>
> _______________________________________________
> Swig-devel mailing list
> Swi...@li...
> https://lists.sourceforge.net/lists/listinfo/swig-devel

-- 
Jitka Plesnikova
Senior Software Engineer
Red Hat

Re: [Swig-devel] use void in prototypes for C functions without arguments

[Patrice D. <per...@fr...>]

On Tue, Sep 02, 2025 at 01:12:22AM -0000, Olly Betts via Swig-devel wrote:
> On 2025-07-29, Patrice Dumas wrote:
> > This kind of issue is shown by gcc when called with -Wstrict-prototypes.
> > If I recall well, empty parentheses in functions definitions should
> > become an error in the default case some day, as this construct has
> > become invalid in the most recent C standard.
> 
> I don't think your recollection is correct.

Indeed, I had erroneously thought that empty parentheses were lumped in
Old-style (K&R) function definition.

-- 
Pat

Re: [Swig-devel] swig-4.4 release dates

[Olly B. <ol...@su...>]

On 2025-08-29, William S Fulton <ws...@fu...> wrote:
> I would like to release swig-4.4 during September prior to the python-3.14
> release. The SWIG release is overdue now with the target date set on the
> milestone https://github.com/swig/swig/milestone/10. I don't think I can
> contribute much to any of the issues on the milestone, except maybe taking
> over #3189 #3192 if that helps you Olly.

That would be helpful - I'm unclear what you want the solution to look
like, and no longer really have any of the context in my head as I last
looked at it nearly 2 months ago.

> Olly, are any of these others a
> blocker and doable by you? Can we aim for something like 28 Sep? If not
> let's bump them off the list.

I'll review what's on the milestone.

Cheers,
    Olly

Re: [Swig-devel] use void in prototypes for C functions without arguments

[Olly B. <ol...@su...>]

On 2025-07-29, Patrice Dumas wrote:
> This kind of issue is shown by gcc when called with -Wstrict-prototypes.
> If I recall well, empty parentheses in functions definitions should
> become an error in the default case some day, as this construct has
> become invalid in the most recent C standard.

I don't think your recollection is correct.

C23 made a C function declaration without arguments equivalent to one
using `void` (which aligns C23 with C++).

https://en.cppreference.com/w/c/language/function_declaration.html says
(see case 3):

| A new style function declaration equivalent to the parameter-list
| void(since C23).

The patch seems reasonable as explicit `void` means a declaration acts
as a prototype for both older and newer C standards, but the
justification that this may break in the future is invalid - this change
is only actually useful for C17 and earlier.

Cheers,
    Olly

[Swig-devel] swig-4.4 release dates

[William S F. <ws...@fu...>]

I would like to release swig-4.4 during September prior to the python-3.14
release. The SWIG release is overdue now with the target date set on the
milestone https://github.com/swig/swig/milestone/10. I don't think I can
contribute much to any of the issues on the milestone, except maybe taking
over #3189 #3192 if that helps you Olly. Olly, are any of these others a
blocker and doable by you? Can we aim for something like 28 Sep? If not
let's bump them off the list.

Otherwise my plan is to work on getting python -builtin to work with the
limited API if nothing else gets in the way.

Please add any essential tickets to the milestone.

William

[Swig-devel] New project creating Tcl interface to Ontrak data acquisition hardware via libusb

[John P. <jo...@ev...>]

The Tcladu project:
https://github.com/johnpeck/tcladu
...uses SWIG to create a Tcl interface to the ADU100 from Ontrak Control
Systems
https://www.ontrak.net/ADU100.htm

Thank you to everyone for your work developing SWIG!

Re: [Swig-devel] use void in prototypes for C functions without arguments

[William S F. <ws...@fu...>]

Hi Patrice

Patch looks fine. We usually accept submissions via github nowadays,
details on https://swig.org/svn.html, but if that is too much let me know.
You may want to also add this flag to Tools/testflags.py so that the
test-suite flushes out future regressions.

William

On Tue, 29 Jul 2025 at 20:05, Patrice Dumas via Swig-devel <
swi...@li...> wrote:

> Hello,
>
> Here is a patch to use void in some C function definition to specify
> that the function does not take argument, replacing empty parentheses.
> My understanding of this is that you almost never want empty parentheses
> as it means something along that the argument can be anything, and not
> that the function does not take arguments.
>
> This kind of issue is shown by gcc when called with -Wstrict-prototypes.
> If I recall well, empty parentheses in functions definitions should
> become an error in the default case some day, as this construct has
> become invalid in the most recent C standard.
>
> I got one of those in the C generated by SWIG for Perl, and I also
> propose modification for a few others.  The tests for c, perl5 and python
> pass with the changes.
>
> There are more similar issues reported by something like
> make check CFLAGS=-Wstrict-prototypes
>
> From a brief look, these do not seem to be intentional.
> There are in particular *SWIG_CException_get_pending and
> *SWIG_CException_reset_pending, but I could not find where they were
> generated.  Some others look like functions defined in tests, but some
> could be generated by SWIG.
>
>
> A changelog entry for the patch could be something along
>
> Use void in C function definitions not taking arguments
>
> --
> Pat
> _______________________________________________
> Swig-devel mailing list
> Swi...@li...
> https://lists.sourceforge.net/lists/listinfo/swig-devel
>

[Swig-devel] use void in prototypes for C functions without arguments

[Patrice D. <per...@fr...>]

Hello,

Here is a patch to use void in some C function definition to specify
that the function does not take argument, replacing empty parentheses.
My understanding of this is that you almost never want empty parentheses
as it means something along that the argument can be anything, and not
that the function does not take arguments.

This kind of issue is shown by gcc when called with -Wstrict-prototypes.
If I recall well, empty parentheses in functions definitions should
become an error in the default case some day, as this construct has
become invalid in the most recent C standard.

I got one of those in the C generated by SWIG for Perl, and I also
propose modification for a few others.  The tests for c, perl5 and python
pass with the changes. 

There are more similar issues reported by something like
make check CFLAGS=-Wstrict-prototypes

>From a brief look, these do not seem to be intentional.
There are in particular *SWIG_CException_get_pending and
*SWIG_CException_reset_pending, but I could not find where they were
generated.  Some others look like functions defined in tests, but some
could be generated by SWIG.


A changelog entry for the patch could be something along

Use void in C function definitions not taking arguments

-- 
Pat

Re: [Swig-devel] Proposal: add SWIG_fail to java

[Mika R. <mik...@ou...>]

Friendly ping.

I still think this would be an improvement to writing java wrappers. Happy
to rework according to feedback.

    Mika

On Fri, 3 Jan 2025 at 15:50, Mika Raento <mik...@ou...> wrote:

> Friendly ping!
>
> I'd appreciate guidance on how to make progress with this change. I do
> think it makes writing correct java wrappers much easier. I'm willing to
> spend time to improve it where necessary.
>
>     Mika
>
> On Mon, Dec 2, 2024 at 7:30 PM Mika Raento <mik...@ou...>
> wrote:
>
>> Dear swig-devel,
>>
>> I'd like to propose adding the SWIG_fail feature to the java target
>> language's code generation. Currently it is quite easy to leak memory in
>> java bindings, as typival early exit code will skip freearg typemaps. (The
>> specific motivation for my case was the memory leak in
>> realm-kotlin's SWIG wrapper, see
>> https://github.com/realm/realm-kotlin/pull/1854. That wrapper can be
>> fixed in other ways but it would be nice to use SWIG_fail there).
>>
>> I've drafted a PR with the code, documentation and test changes:
>> https://github.com/swig/swig/pull/3079 for discussion on the specifics.
>>
>> I guess the main downside is that this will undoubtedly cause some
>> breakage somewhere as it changes the behavior of SWIG_exception for Java,
>> introduces the 'fail:' label that users may have used themselves and adds a
>> new enclosing block for the 'meat' of the generated code so that the goto
>> doesn't skip stack variable initialization.
>>
>> Any guidance on how to make the change less likely to cause breakage
>> would be appreciated.
>>
>> Best,
>>     Mika Raento
>>
>
>
> --
>
> Mika Raento
>
>
>

-- 

Mika Raento

[Swig-devel] Scilab SWIG and unused variables

[William S F. <ws...@fu...>]

Hi Vincent

I made numerous commits to make the SWIG generated code warning free for
gcc's -Wunused-variable with a few exceptions. You can see these leading up
to
https://github.com/swig/swig/commits/1f8684eb540d5d7c63fe7d5c3853990dd2316999/.
Scilab is one of the exceptions that I was unable to sort. Could you please
take a look? I think some of the char array typemaps are incomplete and the
cause of the majority of the warnings. You can check by simply running the
test-suite as follows:

make check-scilab-test-suite CXXFLAGS="-Wunused-variable -std=c++20"
CFLAGS="-Wunused-variable"

Regards
William

[Swig-devel] Announce - swig-4.3.1

[William S F. <ws...@fu...>]

*** ANNOUNCE: SWIG 4.3.1 (15 Apr 2025) ***

https://www.swig.org

We're pleased to announce SWIG-4.3.1, the latest SWIG release.

What is SWIG?
=============

SWIG is a software development tool that reads C/C++ header files and
generates the wrapper code needed to make C and C++ code accessible
from other programming languages including Perl, Python, Tcl, Ruby,
PHP, C#, Go, Java, Javascript, Lua, Scheme (Guile, MzScheme), D,
Ocaml, Octave, R, Scilab.  SWIG can also export its parse tree in
the form of XML.  Major applications of SWIG include generation of
scripting language extension modules, rapid prototyping, testing,
and user interface development for large C/C++ systems.

Release Notes
=============
Detailed release notes are available with the release and are also
published on the SWIG web site at https://swig.org/release.html.

Availability
============
The release is available for download on Sourceforge at

     https://prdownloads.sourceforge.net/swig/swig-4.3.1.tar.gz

A Windows version is also available at

     https://prdownloads.sourceforge.net/swig/swigwin-4.3.1.zip

Please report problems with this release to the swig-devel mailing list,
details at https://www.swig.org/mail.html.

--- The SWIG Developers

Re: [Swig-devel] swig-4.3.1 patch release

[William S F. <ws...@fu...>]

I have not been feeling well, so will get to this later this week.

William

On Thu, 10 Apr 2025 at 08:49, William S Fulton <ws...@fu...>
wrote:

> I plan to make the 4.3.1 release this weekend. Below I've listed all the
> commits in master since 4.3.0 and marked with 'y' the commits I plan to
> cherry-pick onto the release branch. I've also prefixed with there is an
> associated issue number. I'm only adding regression fixes and really low
> risk non-essential changes. Please let me know if there are other candidate
> commits.
>
> #3067 y 61f0bbe97 Python external_runtime example fixup
> #3067 y 095429213 Add external runtime Python example using typemap
> #3067 y 56afa6e6d Fix Python limited API and external runtime
>         124d8a8c3 Test code for removed methods from std::list for
> compatibility with java.util.List
>         34b71a3bb Fix javac -Xlint warning [this-escape] - JDK 21 in
> director constructors
>         ef0d38bff Support JDK 21 and std::list
>         83be871ee Remove unused JAVA_TOOLS_JAR make variable
>         aaeef05f7 Fix javac -Xlint warning [this-escape] - JDK 21 in STL
> containers
>         390da4d67 Add Java 21 testing
>         37caf2e66 warning fix for cdata Java wrappers for visual c++
>         af6581727 Fix javac -Xlint warnings:
>         c2ad64d0a Java compiler lint warnings fixes in test code
>         a16e3cb8c Add Java compiler linting checks javac -Xlint
>         6b69a05b4 Remove typemaps for signed/usigned wchar_t
>         c3b29f87f Update manual section numbers
>         f3ea85af0 [MzScheme/Racket] Drop support
>         0db0a3994 Omit empty deprecated/experiemtnal lists
>         644c860de remove redundant casts to const char* after using
> GetStringUTFChars function
> #3149 y 3b39c8080 CHANGES.current: Document previous commit
> #3149 y 4bec60866 Update octheaders.hpp
>       y 62d492577 Pin cccl version to 1.4
>         86f061cec User specified CC/CXX detection fix
>         a5568a728 deprecated boost atomic_count.hpp
>         837cc1c06 int conversion warnings
>       y fedb45cf4 Upgrade to cccl-1.4
>         df836dee6 configure: Leave overridden CC/CXX values alone
>         f66ea491e Update AX_CXX_COMPILE_STDCXX to upstream serial 25
>         34d0b35cc Remove can fail for Windows GHA
>         4811cb2a2 GHA update for ubuntu-20.04 EOL (#3133)
>         0cc821269 Strip additional -std flags that autoconf now adds to CC
> and CXX
>         e0ecea47b [ci] Enable Go 1.24 testing
>         e7f50af67 [guile] Add CHANGES entry for ports.i fix
>         e11f216a7 [guile] Fix ports.i
>         2f8137b0f [ci] Mark failing windows.yml jobs as continue-on-error
>         e42b3ca60 Remove unused SKIP_PYTHON3
>         651449ee0 [Python] Remove left-over check for Python 1.x
>         6dbf867d2 Fix handling of corner cases by previous change
>         4a0372aac Improve parsing multi-line expr via skip_balanced()
>         1bff64d5e Don't test against Go 1.24 for now. It doesn't work with
> the default CFLAGS.
>         959dbd4dd Test against Go versions 1.20 and 1.24. Stop testing old
> Go versions.
>         26b0911a7 Add support for $n special variable expansion in the
> names of typemap local variables
>         fe3a7af85 Revert "[Go] Use unsafe.Slice and unsafe.String in Go
> fragments"
>         ff5c118aa [Go] Use unsafe.Slice and unsafe.String in Go fragments
>         e8787615a Regression fix when using -keyword, kwargs or
> compactdefaultargs option
> #2889 y 892be2b80 Fix crash when using directors in Python without limited
> API
>         c67582d0e Revert python to windows-2022.
>         dcca453b4 More %interface docs
>         e1b2d20f6 Destructor declaration correction in docs
>         8fd4df01b CHANGES.current: Add entry for Lua unsigned long long fix
>         e2c3e568f Add Lua test case for long long
>         390844a7d Fix "unsigned long long" being interpreted as "signed
> long long" in Lua
>         db6f488fe Correct docs for libraries requiring .NET 4
>         36ef36dcb Add <errno.h> fragment for errno usage
>         1e4559022 Add memory access violation message to C# docs
> #3070 y f362bb099 Explicitly include errno.h for ERANGE
> #3070 y dfe9d8ea2 [Java] Fix regression wrapping enum values
>         d9edb22d1 %apply and typedefs improvement
>         40b6cc684 Use exact type for temporary variable wrapping
> parameters with default args and compactdefaultargs
>         5c2e83dd1 Typedefs to references fix for the compactdefaultargs
> feature
>         936767da8 Few error message improvements and consistency tweaks
>         3cda507e5 Fix initializer lists used with -keyword or
> compactdefaultargs option
>         7af22e929 Fix pedantic warning in tests
>         7fb816dcb typo fix in docs
> #3058 y ada653aaf Suppress unhelpful GCC/clang warnings in new tests
> #3058 y 4e315cdd7 Fix precedence of casts
>         9187aaf22 [guile] Improve constant wrapping
>         acd508f4b Improve testsuite comment
>         1382a403f Use defined type in cpp11_brackets_expression testcase
>         c77498d5d [Perl] Destroy C++ local variables on exception
>         376911013 Java docs code style corrections
>         c9ce79be7 C# docs code style corrections
>         7635b4033 Improve C# Java docs for memory handling and member
> variable accessors
>         0b4496a73 Fix testsuite SWIG warnings; enable SWIG -Werror
>         ce6d2dd11 Drop support for raw type strings in interface files
>         f84f80c31 Bump version to 4.4.0
>
> William
>
> On Wed, 5 Feb 2025 at 18:33, William S Fulton <ws...@fu...>
> wrote:
>
>> There havn't been many commits to master since 4.3.0 for a swig-4.4
>> release, however there are some regressions which ought to be released
>> sooner rather than later so I was thinking of pushing out a 4.3.1 release
>> soon (like within a month). This is mostly in response to
>> https://github.com/swig/swig/issues/3118, but also all those tagged for
>> 4.3.1 milestone - https://github.com/swig/swig/milestone/12.
>>
>> Any objections? If anyone has any "must have" regression fixes (either to
>> be fixed or already fixed), could they please tag with with the 4.3.1
>> milestone. I'll create a release branch and then I'll cherry-pick the
>> changes onto it like I did for the release-4.1 branch.
>>
>> William
>>
>

Re: [Swig-devel] swig-4.3.1 patch release

[William S F. <ws...@fu...>]

I plan to make the 4.3.1 release this weekend. Below I've listed all the
commits in master since 4.3.0 and marked with 'y' the commits I plan to
cherry-pick onto the release branch. I've also prefixed with there is an
associated issue number. I'm only adding regression fixes and really low
risk non-essential changes. Please let me know if there are other candidate
commits.

#3067 y 61f0bbe97 Python external_runtime example fixup
#3067 y 095429213 Add external runtime Python example using typemap
#3067 y 56afa6e6d Fix Python limited API and external runtime
        124d8a8c3 Test code for removed methods from std::list for
compatibility with java.util.List
        34b71a3bb Fix javac -Xlint warning [this-escape] - JDK 21 in
director constructors
        ef0d38bff Support JDK 21 and std::list
        83be871ee Remove unused JAVA_TOOLS_JAR make variable
        aaeef05f7 Fix javac -Xlint warning [this-escape] - JDK 21 in STL
containers
        390da4d67 Add Java 21 testing
        37caf2e66 warning fix for cdata Java wrappers for visual c++
        af6581727 Fix javac -Xlint warnings:
        c2ad64d0a Java compiler lint warnings fixes in test code
        a16e3cb8c Add Java compiler linting checks javac -Xlint
        6b69a05b4 Remove typemaps for signed/usigned wchar_t
        c3b29f87f Update manual section numbers
        f3ea85af0 [MzScheme/Racket] Drop support
        0db0a3994 Omit empty deprecated/experiemtnal lists
        644c860de remove redundant casts to const char* after using
GetStringUTFChars function
#3149 y 3b39c8080 CHANGES.current: Document previous commit
#3149 y 4bec60866 Update octheaders.hpp
      y 62d492577 Pin cccl version to 1.4
        86f061cec User specified CC/CXX detection fix
        a5568a728 deprecated boost atomic_count.hpp
        837cc1c06 int conversion warnings
      y fedb45cf4 Upgrade to cccl-1.4
        df836dee6 configure: Leave overridden CC/CXX values alone
        f66ea491e Update AX_CXX_COMPILE_STDCXX to upstream serial 25
        34d0b35cc Remove can fail for Windows GHA
        4811cb2a2 GHA update for ubuntu-20.04 EOL (#3133)
        0cc821269 Strip additional -std flags that autoconf now adds to CC
and CXX
        e0ecea47b [ci] Enable Go 1.24 testing
        e7f50af67 [guile] Add CHANGES entry for ports.i fix
        e11f216a7 [guile] Fix ports.i
        2f8137b0f [ci] Mark failing windows.yml jobs as continue-on-error
        e42b3ca60 Remove unused SKIP_PYTHON3
        651449ee0 [Python] Remove left-over check for Python 1.x
        6dbf867d2 Fix handling of corner cases by previous change
        4a0372aac Improve parsing multi-line expr via skip_balanced()
        1bff64d5e Don't test against Go 1.24 for now. It doesn't work with
the default CFLAGS.
        959dbd4dd Test against Go versions 1.20 and 1.24. Stop testing old
Go versions.
        26b0911a7 Add support for $n special variable expansion in the
names of typemap local variables
        fe3a7af85 Revert "[Go] Use unsafe.Slice and unsafe.String in Go
fragments"
        ff5c118aa [Go] Use unsafe.Slice and unsafe.String in Go fragments
        e8787615a Regression fix when using -keyword, kwargs or
compactdefaultargs option
#2889 y 892be2b80 Fix crash when using directors in Python without limited
API
        c67582d0e Revert python to windows-2022.
        dcca453b4 More %interface docs
        e1b2d20f6 Destructor declaration correction in docs
        8fd4df01b CHANGES.current: Add entry for Lua unsigned long long fix
        e2c3e568f Add Lua test case for long long
        390844a7d Fix "unsigned long long" being interpreted as "signed
long long" in Lua
        db6f488fe Correct docs for libraries requiring .NET 4
        36ef36dcb Add <errno.h> fragment for errno usage
        1e4559022 Add memory access violation message to C# docs
#3070 y f362bb099 Explicitly include errno.h for ERANGE
#3070 y dfe9d8ea2 [Java] Fix regression wrapping enum values
        d9edb22d1 %apply and typedefs improvement
        40b6cc684 Use exact type for temporary variable wrapping parameters
with default args and compactdefaultargs
        5c2e83dd1 Typedefs to references fix for the compactdefaultargs
feature
        936767da8 Few error message improvements and consistency tweaks
        3cda507e5 Fix initializer lists used with -keyword or
compactdefaultargs option
        7af22e929 Fix pedantic warning in tests
        7fb816dcb typo fix in docs
#3058 y ada653aaf Suppress unhelpful GCC/clang warnings in new tests
#3058 y 4e315cdd7 Fix precedence of casts
        9187aaf22 [guile] Improve constant wrapping
        acd508f4b Improve testsuite comment
        1382a403f Use defined type in cpp11_brackets_expression testcase
        c77498d5d [Perl] Destroy C++ local variables on exception
        376911013 Java docs code style corrections
        c9ce79be7 C# docs code style corrections
        7635b4033 Improve C# Java docs for memory handling and member
variable accessors
        0b4496a73 Fix testsuite SWIG warnings; enable SWIG -Werror
        ce6d2dd11 Drop support for raw type strings in interface files
        f84f80c31 Bump version to 4.4.0

William

On Wed, 5 Feb 2025 at 18:33, William S Fulton <ws...@fu...>
wrote:

> There havn't been many commits to master since 4.3.0 for a swig-4.4
> release, however there are some regressions which ought to be released
> sooner rather than later so I was thinking of pushing out a 4.3.1 release
> soon (like within a month). This is mostly in response to
> https://github.com/swig/swig/issues/3118, but also all those tagged for
> 4.3.1 milestone - https://github.com/swig/swig/milestone/12.
>
> Any objections? If anyone has any "must have" regression fixes (either to
> be fixed or already fixed), could they please tag with with the 4.3.1
> milestone. I'll create a release branch and then I'll cherry-pick the
> changes onto it like I did for the release-4.1 branch.
>
> William
>

[Swig-devel] swig-4.3.1 patch release

[William S F. <ws...@fu...>]

There havn't been many commits to master since 4.3.0 for a swig-4.4
release, however there are some regressions which ought to be released
sooner rather than later so I was thinking of pushing out a 4.3.1 release
soon (like within a month). This is mostly in response to
https://github.com/swig/swig/issues/3118, but also all those tagged for
4.3.1 milestone - https://github.com/swig/swig/milestone/12.

Any objections? If anyone has any "must have" regression fixes (either to
be fixed or already fixed), could they please tag with with the 4.3.1
milestone. I'll create a release branch and then I'll cherry-pick the
changes onto it like I did for the release-4.1 branch.

William

Re: [Swig-devel] Proposal: add SWIG_fail to java

[Mika R. <mik...@ou...>]

Friendly ping!

I'd appreciate guidance on how to make progress with this change. I do
think it makes writing correct java wrappers much easier. I'm willing to
spend time to improve it where necessary.

    Mika

On Mon, Dec 2, 2024 at 7:30 PM Mika Raento <mik...@ou...> wrote:

> Dear swig-devel,
>
> I'd like to propose adding the SWIG_fail feature to the java target
> language's code generation. Currently it is quite easy to leak memory in
> java bindings, as typival early exit code will skip freearg typemaps. (The
> specific motivation for my case was the memory leak in
> realm-kotlin's SWIG wrapper, see
> https://github.com/realm/realm-kotlin/pull/1854. That wrapper can be
> fixed in other ways but it would be nice to use SWIG_fail there).
>
> I've drafted a PR with the code, documentation and test changes:
> https://github.com/swig/swig/pull/3079 for discussion on the specifics.
>
> I guess the main downside is that this will undoubtedly cause some
> breakage somewhere as it changes the behavior of SWIG_exception for Java,
> introduces the 'fail:' label that users may have used themselves and adds a
> new enclosing block for the 'meat' of the generated code so that the goto
> doesn't skip stack variable initialization.
>
> Any guidance on how to make the change less likely to cause breakage would
> be appreciated.
>
> Best,
>     Mika Raento
>


-- 

Mika Raento

Re: [Swig-devel] Toolchain upgrade for C#

[William S F. <ws...@fu...>]

On Mon, 25 Nov 2024 at 16:06, Vadim Zeitlin <vz...@ze...> wrote:

> On Mon, 25 Nov 2024 14:46:05 +0000 Christophe CALMEJANE via Swig-devel <
> swi...@li...> wrote:
>
> CC> Still my main question remains, has it been considered to migrate from
> the
> CC> deprecated mono compiler to Microsoft Dotnet one?
>
>  I think this would require a significant effort because, AFAIK, dotnet
> toolchain can't be used to compile individual C# source files, as the
> traditional compilers do, and what SWIG makefiles use, and requires
> creating a
> project for each and every test.
>
>  But please correct me if I'm wrong, I could have missed something.


I have started looking at this. It seems that dotnet does not support C++
.vcxproj files, so we can't even use dotnet for the examples under
Examples/csharp. I had some luck running these examples under Linux though
by suppressing the csc.exe / mono-csc.exe invocation and then using dotnet
commands to create a project to build the C# layer. These are the steps for
the Examples/csharp/class example:


rm example-vc.vcxproj example-cs.csproj example.sln
dotnet new console -n example -o .
rm Program.cs
make COMPILETOOL=true RUNTOOL=true # To invoke swig and compile the
generated c/c++ code, suppresses invoking C# compiler and running the
example
dotnet build -nowarn:CS8981
env LD_LIBRARY_PATH=. dotnet run

Building quietly required some extra options...
dotnet build --verbosity quiet -clp:NoSummary

I think this has potential to work once autoconf is modified to detect
dotnet and modify the build accordingly. I'll try go in this direction
next. It would indeed need to create a project for each test (via dotnet
new). It generates a tiny example.csproj file:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net8.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
  </PropertyGroup>

</Project>

and doesn't take long. It finds all the .cs files in the current directory
including subdirectories. The test-suite might work by soft linking the
appropriate runme.cs file to the Examples/test-suite/csharp directory from
the testcase subdirectory that contains the generated C# files as all the
files will then be in a self-contained directory tree. It is possible to
write dotnet templates for 'dotnet new' which might be worth exploring.

William

[Swig-devel] Proposal: add SWIG_fail to java

[Mika R. <mik...@ou...>]

Dear swig-devel,

I'd like to propose adding the SWIG_fail feature to the java target
language's code generation. Currently it is quite easy to leak memory in
java bindings, as typival early exit code will skip freearg typemaps. (The
specific motivation for my case was the memory leak in
realm-kotlin's SWIG wrapper, see
https://github.com/realm/realm-kotlin/pull/1854. That wrapper can be fixed
in other ways but it would be nice to use SWIG_fail there).

I've drafted a PR with the code, documentation and test changes:
https://github.com/swig/swig/pull/3079 for discussion on the specifics.

I guess the main downside is that this will undoubtedly cause some breakage
somewhere as it changes the behavior of SWIG_exception for Java, introduces
the 'fail:' label that users may have used themselves and adds a new
enclosing block for the 'meat' of the generated code so that the goto
doesn't skip stack variable initialization.

Any guidance on how to make the change less likely to cause breakage would
be appreciated.

Best,
    Mika Raento

Re: [Swig-devel] Post 4.3.0 release perspective

[William S F. <ws...@fu...>]

On Thu, 24 Oct 2024 at 22:36, Olly Betts <ol...@su...> wrote:

> On 2024-10-21, William S Fulton <ws...@fu...> wrote:
> > Looking at the https://swig.org/mail.html page on the web site, I was
> > considering updating it given the mailing lists seem to have gone out of
> > fashion a bit.
> >
> > 1. The GMane and Nabble mailing list search facility no longer works, so
> > I'll remove that. I don't know of any replacements, but the SourceForge
> > search doesn't seem so bad these days too, which is good.
>
> I can confirm the Gmane search is gone (as it happens I used to run it!)
> as has the web frontend - Gmane is now only an NNTP gateway and archive
> of mailing lists and that part still works (I'm posting this using it).
>
> > 2. I think we should suggest users also try stackoverflow for support as
> > that seems to be the modern way and currently more popular than the
> > swig-user mailing list.
>
> I really don't like stackoverflow, and don't like the idea that we
> might promote it as a place to get help.
>
> I especially dislike that it tends to dominate in general web search
> results, but usually isn't actually the best place to get a definitive
> answer to something.
>
> Its mechanism for promoting answers isn't terrible but it can only
> promote the best answer that someone on stackoverflow gave, and it can
> suffer from group-think where the promoted answer is what is generally
> believed but not what is actually correct.
>
> It also seems to have a lot of questions where there are no useful
> answers, but which still rank well in general web search results.
>
> Not related to usefulness, but stackoverflow also seems to be run by a
> company that does not treat its volunteer moderators well.
>
> > I was also half thinking of suggesting to use Github discussions for
> > general user help.
>
> I can't say that idea fills me with joy either.
>

Regarding the emailing list and general community support, I have updated
https://swig.org/mail.html taking into account these and subsequent
comments as well as what the SWIG community uses.

I did a quick analysis of where the community goes for support and came up
with the following analysis covering the last year Dec 2023 - Nov 2024. I
compared the 3 main areas that seem to be the places that uses actually go
to for support:

1. Stackoverflow tagged with [swig] -
https://stackoverflow.com/questions/tagged/swig
2. swig-user mailing list -
https://sourceforge.net/p/swig/mailman/swig-user/
3. Github discussions -
https://github.com/swig/swig/discussions?discussions_q=sort%3Adate_created

Total questions asked on Stackoverflow: 67
Total threads/questions asked on swig-user: 30
Total Github discussions threads: 23

The place that users go to for asking questions is ordered as above.

Success rate is rather hard to measure, but we have:

Total questions marked as answered on Stackoverflow for the 67 questions: 29

Total posts on swig-user for the 30 threads: 74
Total posts on swig-user for the 30 threads with a reply: 26

Total posts for the 23 threads on Github discussions: 70
Total of the 23 threads marked as answered on Github discussions:7

Success rate is possibly best on Stackoverflow and swig-user, but most
activity is on Github discussions. Caveat: I make a particular effort to
try and at least reply to most swig-user queries.

I'm not sure we can conclude anything definitive with respect to where the
best success rate is for help.

Feel free to pick holes in this and find other options for community
support, but given the mixed bag that users actually go to, I've mentioned
all three without recommending any one over the other. I'd rather give
links to what is actually useful rather than mandate any one place over
another for now. However, I have made it clear where to file bugs and
patches in the list of options at https://swig.org/mail.html. But if anyone
has further improvements, please raise merge requests for the web pages at
https://github.com/swig/www/.

William

Re: [Swig-devel] Toolchain upgrade for C#

[Christophe C. <chr...@l-...>]

Hi,

I did wrote some helper function to add C# target to a CMake project using the dotnet tool, not sure if it’s of any help or is the kind of thing you are asking for (see here: https://github.com/christophe-calmejane/cmakeUtils/blob/main/helpers/GenerateCSharpTarget.cmake ).

I looked at the nullable reference support you mentioned in swig 4.2, which is great to let the user decide if he wants to use C#8 features or not.
The only downside I’ve seen so far is that it’s causing quite a lot of warnings in the PINVOKE auto-generated file. Is there any way to not set ‘#nullable enable’ in this file (or overwrite it)? Or add additional flags to silence the warnings just for that file?

private static global::System.Exception pendingException = null;

  *   Cannot convert null literal to non-nullable reference type.
global::System.Exception e = null;

  *   Converting null literal or possible null value to non-nullable type.
And so on..

Thanks for the help.

Christophe





De : William S Fulton <ws...@fu...>
Date : mardi, 26 novembre 2024 à 20:51
À : Mario Emmenlauer <ma...@em...>
Cc : Christophe CALMEJANE <chr...@l-...>, swi...@li... <swi...@li...>
Objet : Re: [Swig-devel] Toolchain upgrade for C#


On Mon, 25 Nov 2024 at 15:46, Mario Emmenlauer via Swig-devel <swi...@li...<mailto:swi...@li...>> wrote:

Dear Christophe,

thanks a lot for your great interest!


On 25.11.24 15:46, Christophe CALMEJANE via Swig-devel wrote:
> Still my main question remains, has it been considered to migrate from the deprecated mono compiler to Microsoft Dotnet one?

Yes, we have weighted and considered the options, and after some careful
consideration, we agree that you can provide a PR, so we can understand and
discuss the changes directly on the diffset.

Please see https://github.com/apache/thrift/blob/master/CONTRIBUTING.md for
more info, and thanks a lot for your support!

I'm not sure what the Apache Thrift contributing link has to do with contributing to SWIG!

In answer to your question, SWIG aims to generate C# code that will work with the versions of .NET that I mentioned earlier in the chain. Users can use whatever C# compiler they like that supports these versions. With regards to the compiler versions supported in the SWIG test-suite and examples for testing, I would happily accept a patch that supports modern dotnet toolsuite that Microsoft provide. But as Vadim points out it isn't clear how the dotnet toolchain can easily fit in with our makefiles for building the unmanaged code, but I really would like someone to help in this space. If there was some sort of example that show how to use the toolchain for a project that uses PInvoke and C code, it might provide the info required.

William

Re: [Swig-devel] Toolchain upgrade for C#

[William S F. <ws...@fu...>]

On Mon, 25 Nov 2024 at 15:46, Mario Emmenlauer via Swig-devel <
swi...@li...> wrote:

>
> Dear Christophe,
>
> thanks a lot for your great interest!
>
>
> On 25.11.24 15:46, Christophe CALMEJANE via Swig-devel wrote:
> > Still my main question remains, has it been considered to migrate from
> the deprecated mono compiler to Microsoft Dotnet one?
>
> Yes, we have weighted and considered the options, and after some careful
> consideration, we agree that you can provide a PR, so we can understand and
> discuss the changes directly on the diffset.
>
> Please see https://github.com/apache/thrift/blob/master/CONTRIBUTING.md
> for
> more info, and thanks a lot for your support!


I'm not sure what the Apache Thrift contributing link has to do with
contributing to SWIG!

In answer to your question, SWIG aims to generate C# code that will work
with the versions of .NET that I mentioned earlier in the chain. Users can
use whatever C# compiler they like that supports these versions. With
regards to the compiler versions supported in the SWIG test-suite and
examples for testing, I would happily accept a patch that supports modern
dotnet toolsuite that Microsoft provide. But as Vadim points out it isn't
clear how the dotnet toolchain can easily fit in with our makefiles for
building the unmanaged code, but I really would like someone to help in
this space. If there was some sort of example that show how to use the
toolchain for a project that uses PInvoke and C code, it might provide the
info required.

William