Re: [Swig-devel] Fwd: Warning 303 after upgrading to swig 3.0

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

Thanks, I've merged this in for 3.0.2.

William

On 28/05/14 19:20, Vladimir Kalinin wrote:
> Hi Diego,
>
> Sorry, I overlooked the fact that the scope for the nested structs was
> reset before %extend hash is merged.
> I pushed a patch: https://github.com/swig/swig/pull/183,
> <https://github.com/swig/swig/pull/183> let's see how Travis builds will
> pass.
>
> Best regards,
>   Vladimir mailto:VKa...@op...
>
> -----Original Message-----
> Hi William, Vladimir,
>
> Thanks for looking into this.  I tried this with the code in the master
> branch and it seems to be resolved.  One of the use cases I wanted from
> this was to know the size of the structures in C by adding an attribute
> for them.  Unfortunately, I see another issue now with these attributes
> overriding each other in nested structures.  See below.
>
> // demo_header.h
> typedef struct foo {
>      int a;
>      union {
>          char c;
>          int d;
>      } bar;
>
>      struct {
>          char *name;
>      } low;
> } FOO;
>
> // demo_interface.i
> %module demo_header
> %{
> #include "./demo_header.h"
> %}
>
> %include "./demo_header.h"
>
> %extend foo {
>      static const long swig_size = sizeof(foo);
> };
>
> %extend foo_bar {
>      static const long swig_size = sizeof(foo_bar);
> };
>
> %extend foo_low {
>      static const long swig_size = sizeof(foo_low);
> };
>
> // build command
> swig -Wall -I. -outdir ./tmp -java demo_interface.i
>
> // output
> demo_interface.i:10: Warning 302: Identifier 'swig_size' redefined by
> %extend (ignored),
> demo_interface.i:14: Warning 302: %extend definition of 'swig_size'.
> demo_interface.i:14: Warning 302: Identifier 'swig_size' redefined by
> %extend (ignored),
> demo_interface.i:18: Warning 302: %extend definition of 'swig_size'.
>
> Can you please look into this?
>
> Best,
> Diego Montemayor
>
>
>
> On Wed, May 21, 2014 at 3:57 PM, William S Fulton
> <ws...@fu... <mailto:ws...@fu...>> wrote:
> Thanks for restoring this behaviour Vladimir. I also don't like it, but
> so be it. I'd rather not have these made up C symbols added to the
> symbol table, but unless we come up with some sort of generic
> alternative way of handling unnamed types, it'll have to remain that way.
>
> I can't say I've ever seen a global anonymous struct myself in the wild,
> but I don't follow what your concern is. In C you can just use it like
>
>    THING.a = 123;
>
> for the example below. If there is a header containing one of these,
> then duplicates could occur, but that is the case for any instance
> declared in a header file and is probably why you don't see them much.
>
> Someone might want to use SWIG code to write one:
>
> %inline %{
> struct {
>    int a;
> } THING;
> %}
>
> which won't cause any linking problems. However as SWIG has never
> wrapped them, it won't work and I think we should continue to silently
> ignore them ... I propose that your seg fault fix is good enough. If we
> had a better unnamed type strategy for nested unnamed types, we could no
> doubt apply it to these global ones, so am open to good ideas there.
>
> William
>
>
> On 14/05/14 00:16, Vladimir Kalinin wrote:
> Hi William,
>
> I fixed %extend for unnamed structures, so that it would work like
> before, see https://github.com/swig/swig/pull/175
> The solution is far from ideal, but the whole renaming thing is a gross
> hack, so
> a few more twists won't harm, I think.
>
> Will fix global anonymous structs later.
> BTW, I don't quite understand how such global instances may be used -
> won't they get duplicated in wrappers code and in the native library
> itself?
>
> Best regards,
>    Vladimir                          mailto:VKa...@op...
> <mailto:VKa...@op...>
>
> -----Original Message-----
>
> Vladimir,
>
> In 2.0, not a lot was generated for THING. A type wrapper class is
> available in Java, SWIGTYPE_p__unnamed1_.java, which is basically SWIG
> giving up... it does not provide anything useful to access the members.
> I think we should silently ignore it now instead. At least until we come
> up with a general way to tackle other unnamed types, if we do. It is
> kind of similar to trying to use types in a C++ anonymous namespace in gdb.
>
> I'm more concerned with the example that Diego posted. How about going
> back to what is documented for unnamed types:
> http://swig.org/Doc3.0/SWIG.html#SWIG_nested_structs and fixing the docs
> for the new named C nested types. Actually, I think it is working like
> this, just the symbol tables are not correct and need to go back what
> was in 2.0. Nesting that is deep with a mix of named and unnamed types
> will need some thought and testing too.
>
> At least in C++ any unnamed nested types are ignored... best to keep
> that, but we need some solution for C.
>
> William
>
>
> On 10/05/14 19:31, Vladimir Kalinin wrote:
> Hi William,
>
> The first issue seems to be trivial, I sent a pull request,
> https://github.com/swig/swig/pull/173
>
> About global anonymous structures there is a problem: C allows the
> following declarations to live simultaneously in global scope:
>
> struct {
>      double a;
> } THING;
>
> struct THING {
>      int b;
> };
>
> so, I'm not sure how to generate a name for that global unnamed
> structure. Perhaps we can prepend a module name to the variable name,
> like in the nested case.
> The segfault should be fixed of course - now we just don't assign any
> type to such a structure.
>
> Best regards,
>     Vladimir                          mailto:VKa...@op...
> <mailto:VKa...@op...>
>
> -----Original Message-----
>
> Vladimir,
>
> Would you mind looking at this? It seems that the C symbols for nested
> classes aren't always quite right. For example:
>
> typedef struct FOO {
>         int a;
>         union bar {
>             char c;
>             int d;
>         } bar_instance;
>
>         struct low {
>             char *name;
>         } low_instance;
> } FOO;
>
> shows when run with -debug-csymbols as:
>
> CSYMBOLS start  =======================================
> ===================================================
>      -
>       low (class)
>       FOO (class)
>       bar (class)
> ===================================================
> FOO::low -
>       name (cdecl)
> ===================================================
> FOO -
>       bar_instance (cdecl)
>       low_instance (cdecl)
>       a (cdecl)
> ===================================================
> FOO::bar -
>       c (cdecl)
>       d (cdecl)
> CSYMBOLS finish =======================================
>
> I'd say that FOO::bar should be bar and likewise FOO::low should be low.
> This is actually the case when 'typedef struct FOO' above is changed to
> 'typedef struct'. %extend bar { ... } would then work in the above case.
>
> With Diego's code below, I'm not really sure what to do with the
> anonymous type for bar and low. I thought I'd take some inspiration from
> the global version:
>
> struct {
>       int i;
> } THING;
>
> but it now seg faults, so also needs a fix. In SWIG 2, THING generated a
> SWIGTYPE_p___unnamed1.java type wrapper class, so is effectively
> useless. Probably for the nested anonymous class, we just can't use
> extend as there is simply no type info. I also think where we currently
> generate FOO_low_instance as a type and don't create THING as a type is
> inconsistent.
>
> William
>
> On 08/05/14 13:24, Diego Montemayor wrote:
> Hi William,
>
> Thanks for the prompt reply. I tried using both colons as suggested but
> had no success.  I made a test to illustrate this, please see below.
>
> Regards,
> Diego Montemayor
>
> /// nested_demo.h/
> typedef struct {
>         int a;
>         union {
>             char c;
>             int d;
>         } bar;
>
>         struct {
>             char *name;
>         } low;
> } FOO;
>
> // nested_demo.i
> %module nested_demo
> %{
> #include "../include/nested_demo.h"
> %}
>
> %include "../include/nested_demo.h"
>
> %extend FOO {
> };
>
> %extend FOO_bar {
> };
>
> %extend FOO_low {
> };
>
> //build command
> swig -Wall -I../include/ -outdir ./tmp -java nested_demo.i
>
> //output
> nested_demo.i:16: Warning 303: %extend defined for an undeclared class
> FOO::low.
> nested_demo.i:13: Warning 303: %extend defined for an undeclared class
> FOO_bar.
>
>
>
> On Wed, May 7, 2014 at 4:00 PM, William S Fulton
> <ws...@fu...
> <mailto:ws...@fu...> <mailto:ws...@fu...
> <mailto:ws...@fu...>>> wrote:
>
>        Have done now. I meant to include Vladimir on the reply but forgot
>        as he put in place most of the nested changes. Can you include him
>        in any reply please? ... Vladimir Kalinin
> <vka...@op... <mailto:VKa...@op...>
>        <mailto:vka...@op... <mailto:VKa...@op...>>>
>
>        William
>
>
>        On 07/05/14 19:34, Diego Montemayor wrote:
>
>            Hi William,
>
>            Can you please followup on this issue?  I ran the same code
> on swig
>            2.0.12 and swig 3.0.0.  The previous version of swig
> processes the
>            extend correctly (I can confirm by looking at the .java files)
>            while the
>            newer version throws this warning and ignores the extend.  Is
> there
>            something I am missing?
>
>            Best regards,
>            Diego Montemayor
>
>            ---------- Forwarded message ----------
>            From: *Diego Montemayor* <die...@gm...
> <mailto:die...@gm...>
>            <mailto:die...@gm...
> <mailto:die...@gm...>>
>            <mailto:diegomontemayors@
> <mailto:diegomontemayors@>__gmail.com <http://gmail.com>
>            <mailto:die...@gm...
> <mailto:die...@gm...>>>>
>            Date: Fri, May 2, 2014 at 1:32 PM
>            Subject: Re: Warning 303 after upgrading to swig 3.0
>            To: swi...@li...urceforge.__net
>            <mailto:swi...@li...
> <mailto:swi...@li...>>
>            <mailto:swig-user@lists.
> <mailto:swig-user@lists.>__sourceforge.net <http://sourceforge.net>
>            <mailto:swi...@li...
> <mailto:swi...@li...>>>
>
>
>            This is true, but it shouldn't apply here since I'm working with
>            C code.
>               Here is the notation I'm using on the extent statements, is
>            this correct?
>
>            %extend FOO_subfoo {
>            ...
>            };
>
>
>            On 05/01/2014 05:55 PM, Diego Montemayor wrote:
>
>                Hi all,
>
>                I recently upgraded to swig 3.0 and started seeing some
>                warnings without
>                changing any of the code.
>
>                *Warning 303: %extend defined for an undeclared class
>                FOO_subfoo*
>
>                I noticed that these warnings are all for unions inside
>                structures or
>                nested structures (not typedefined).  I don't see this error
>                when running
>                swig on version 2.0 so I'm not sure what has changed.
>
>
>            The v3 announcement says "Nested class support added"... That's
>            probably what has changed.
>
>
>
>                I ran it in debug mode and posted the class info below. Any
>                idea what's
>                going on here?
>
>                Thanks,
>                Diego
>
>                        +++ *class
> *-----------------------------__-----------
>                        | classtype    - "FOO_subfoo"
>                        | unnamed      - "$unnamed16$"
>                        | name         - "FOO_subfoo"
>                        | ismember     - "1"
>                        | symtab       - 0x1e044e0
>                        | allows_typedef - "1"
>                        | sym:symtab   - 0x7ffc71ad8910
>                        | typepass:visit - "1"
>                        | allocate:visit - "1"
>                        | kind         - "union"
>                        | sym:name     - "FOO_subfoo"
>                        | allocate:default_constructor - "1"
>                        | allocate:default_destructor - "1"
>                        | allocate:copy_constructor - "1"
>                        | has_default_constructor - "1"
>                        | has_destructor - "1"
>                        | allocate:destructor - "1"
>                        | has_constructor - "1"
>                        | tdname       - "FOO_subfoo"
>                        | classtypeobj - "FOO_subfoo"
>                        | feature:java:enum - "typesafe"
>                        | access       - "public"
>                        | module       - 0x1dc1960
>                        | nested       - "1"
>                        | sym:overname - "__SWIG_0"
>                        | typescope    - 0x6cd2d20
>                        | proxyname    - "FOO_subfoo"
>
>
>
>
> ------------------------------__------------------------------__------------------
>                "Accelerate Dev Cycles with Automated Cross-Browser Testing
>                - For FREE
>                Instantly run your Selenium tests across 300+ browser/OS
>                combos.  Get
>                unparalleled scalability from the best Selenium testing
>                platform available.
>                Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
>
>
>
>                _________________________________________________
>                Swig-user mailing list
>                Swig-user@...
> https://lists.sourceforge.net/__lists/listinfo/swig-user
>                <https://lists.sourceforge.net/lists/listinfo/swig-user>
>
>
>
>
>
>
>
>
> -----
> В этом сообщении вирусы не обнаружены.
> Проверено AVG - www.avg.com <http://www.avg.com>
> Версия: 2012.0.2247 / Вирусная база данных: 3722/6964 - Дата выпуска:
> 09.05.2014
>
>
>
>
>
> -----
> В этом сообщении вирусы не обнаружены.
> Проверено AVG - www.avg.com <http://www.avg.com>
> Версия: 2012.0.2247 / Вирусная база данных: 3722/6981 - Дата выпуска:
> 12.05.2014
>

Re: [Swig-devel] Fwd: Warning 303 after upgrading to swig 3.0

A code generator for connecting C/C++ with other programming languages

Re: [Swig-devel] Fwd: Warning 303 after upgrading to swig 3.0