swig-devel — SWIG Developer List

[Swig-devel] Announce - swig-4.4.1

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

*** ANNOUNCE: SWIG 4.4.1 (7 Dec 2025) ***

https://www.swig.org

We're pleased to announce SWIG-4.4.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), 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.4.1.tar.gz

A Windows version is also available at

     https://prdownloads.sourceforge.net/swig/swigwin-4.4.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] Heads up: swig-4.4.1 release

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

Hi Jeff

We post the releases on SourceForge still, see
https://swig.org/download.html, that's the official location. We don't
really have the bandwidth for supporting two ways of releasing SWIG. I
would be okay with moving all the existing releases to Github and then only
posting new releases on Github, but I havn't looked into it. If someone who
is familiar with all this can outline with plenty of detail what needs
doing I can possibly do it.

William

On Fri, 5 Dec 2025 at 13:52, Jeff McKenna <jmc...@ga...>
wrote:

> Thanks for the heads-up.  (also, for 4.4.1, it would be great if you can
> post the release at https://github.com/swig/swig/releases so all of the
> 'followers' of the repo get automagically notified.
>
> thanks again,
>
> -jeff
>
>
> On 2025-12-05 4:26 a.m., William S Fulton wrote:
> > The only issue reported since swig-4.4.0 was released is https://
> > github.com/swig/swig/pull/3287 <https://github.com/swig/swig/pull/3287>
> > to fix Py_LIMITED_API<3.11. I think it is severe enough to issue a patch
> > release. I plan on releasing swig-4.4.1 with this in it on Sunday. I've
> > created the https://github.com/swig/swig/commits/refs/heads/
> > release-4.4/.Are <https://github.com/swig/swig/commits/refs/heads/
> > release-4.4/.Are> there any other important regressions to go into this
> > release?
> >
> > William
> >
> >
> > _______________________________________________
> > Swig-devel mailing list
> > Swi...@li...
> > https://lists.sourceforge.net/lists/listinfo/swig-devel
>
>
> --
> Jeff McKenna
> GatewayGeo: Developers of MS4W, & offering MapServer Consulting/Dev
> co-founder of FOSS4G
> http://gatewaygeo.com/
>
>
> _______________________________________________
> Swig-devel mailing list
> Swi...@li...
> https://lists.sourceforge.net/lists/listinfo/swig-devel
>

Re: [Swig-devel] Heads up: swig-4.4.1 release

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

Yes, indeed I overlooked that, the code was introduced by
https://github.com/swig/swig/commit/c840bb728a886fd8b9a9f241c2d2b603f0e7a91b.
I'll add #3284 then to the release.

William

On Fri, 5 Dec 2025 at 11:57, Markus Wick <ma...@sw...>
wrote:

> Hi William,
>
> My already merged PR https://github.com/swig/swig/pull/3284 was
> technically also a regression of 4.4.0, but I wouldn't call it important at
> all.
>
> I'm fine with both picking or not picking in 4.4.1.
>
> Thanks for maintaining SWIG!
>
> Best regards,
>
> Markus
>
> --
> Markus Wick
> Swabian Instruments GmbH
> Stammheimer Str. 41 | 70435 Stuttgart | Germany
> HRB 758962 (Stuttgart)  |  Geschäftsführer: Michael Schlagmüller
>
>
> Am Fr., 5. Dez. 2025 um 11:06 Uhr schrieb William S Fulton <
> ws...@fu...>:
>
>> The only issue reported since swig-4.4.0 was released is
>> https://github.com/swig/swig/pull/3287 to fix Py_LIMITED_API<3.11. I
>> think it is severe enough to issue a patch release. I plan on releasing
>> swig-4.4.1 with this in it on Sunday. I've created the
>> https://github.com/swig/swig/commits/refs/heads/release-4.4/.Are there
>> any other important regressions to go into this release?
>>
>> William
>> _______________________________________________
>> Swig-devel mailing list
>> Swi...@li...
>> https://lists.sourceforge.net/lists/listinfo/swig-devel
>>
>

Re: [Swig-devel] Heads up: swig-4.4.1 release

[Jeff M. <jmc...@ga...>]

Thanks for the heads-up.  (also, for 4.4.1, it would be great if you can 
post the release at https://github.com/swig/swig/releases so all of the 
'followers' of the repo get automagically notified.

thanks again,

-jeff


On 2025-12-05 4:26 a.m., William S Fulton wrote:
> The only issue reported since swig-4.4.0 was released is https:// 
> github.com/swig/swig/pull/3287 <https://github.com/swig/swig/pull/3287> 
> to fix Py_LIMITED_API<3.11. I think it is severe enough to issue a patch 
> release. I plan on releasing swig-4.4.1 with this in it on Sunday. I've 
> created the https://github.com/swig/swig/commits/refs/heads/ 
> release-4.4/.Are <https://github.com/swig/swig/commits/refs/heads/ 
> release-4.4/.Are> there any other important regressions to go into this 
> release?
> 
> William
> 
> 
> _______________________________________________
> Swig-devel mailing list
> Swi...@li...
> https://lists.sourceforge.net/lists/listinfo/swig-devel


-- 
Jeff McKenna
GatewayGeo: Developers of MS4W, & offering MapServer Consulting/Dev
co-founder of FOSS4G
http://gatewaygeo.com/

[Swig-devel] Heads up: swig-4.4.1 release

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

The only issue reported since swig-4.4.0 was released is
https://github.com/swig/swig/pull/3287 to fix Py_LIMITED_API<3.11. I think
it is severe enough to issue a patch release. I plan on releasing
swig-4.4.1 with this in it on Sunday. I've created the
https://github.com/swig/swig/commits/refs/heads/release-4.4/.Are there any
other important regressions to go into this release?

William

[Swig-devel] Announce - swig-4.4.0

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

*** ANNOUNCE: SWIG 4.4.0 (20 Oct 2025) ***

https://www.swig.org

We're pleased to announce SWIG-4.4.0, 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), 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.4.0.tar.gz

A Windows version is also available at

     https://prdownloads.sourceforge.net/swig/swigwin-4.4.0.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.4 release dates

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

On Wed, 15 Oct 2025 at 00:08, Patrice Dumas <per...@fr...> wrote:

> On Tue, Oct 14, 2025 at 09:02:18AM +0100, William S Fulton wrote:
> > I just have https://github.com/swig/swig/issues/3266 in the list of
> > unresolved issues in https://github.com/swig/swig/milestone/10 for the
> > 4.4.0 release. I think I can resolve that later this week, in which case
> I
> > would like to do the actual release on the weekend. If there is any other
> > minimally impacting change, now is the chance to merge to master.
>
> What I reported the other day looks minimal to me, but you may disagree.
> Here it is again without the wrong point.
>
> 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 is that one 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.
>
> 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.
>
> This kind of issue is shown by gcc when called with -Wstrict-prototypes.
> 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
>

Thanks, applied in de640927515eba2c9944b8e516455c916a82e261.

We should use -Wstrict-prototypes for testing, however, there is more work
to be done in the tests to make them warning free, then we can add this
compiler flag into Tools/testflags.py. Github pull requests welcome!

William

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

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

On Tue, Oct 14, 2025 at 09:02:18AM +0100, William S Fulton wrote:
> I just have https://github.com/swig/swig/issues/3266 in the list of
> unresolved issues in https://github.com/swig/swig/milestone/10 for the
> 4.4.0 release. I think I can resolve that later this week, in which case I
> would like to do the actual release on the weekend. If there is any other
> minimally impacting change, now is the chance to merge to master.

What I reported the other day looks minimal to me, but you may disagree.
Here it is again without the wrong point.

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 is that one 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.

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.

This kind of issue is shown by gcc when called with -Wstrict-prototypes.
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] swig-4.4 release dates

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

I just have https://github.com/swig/swig/issues/3266 in the list of
unresolved issues in https://github.com/swig/swig/milestone/10 for the
4.4.0 release. I think I can resolve that later this week, in which case I
would like to do the actual release on the weekend. If there is any other
minimally impacting change, now is the chance to merge to master.

William

On Fri, 5 Sept 2025 at 12:24, Jitka Plesnikova via Swig-devel <
swi...@li...> wrote:

>
>
> 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
>
> _______________________________________________
> Swig-devel mailing list
> Swi...@li...
> https://lists.sourceforge.net/lists/listinfo/swig-devel
>

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