headers
skaller | 1 Jan 2004 02:57
Picon
Picon

Preprocessor bug

Swig preprocessor does not concatenate lines 
ending in \ correctly in all circumstances. 

It appears the expression evaluation
is correct, it just doesnt concatente, but its more
complicated, maybe it is dropping the stack or something
when it concatenates ?

input:

#if 1 ||\
(0 &&1)
#define stdc 1
#else
#define stdc 0
#endif

output (felix module but doesn't matter): WRONG!

  const stdc: int = '0';

input:
#if 1 || (0 &&1)
#define stdc 1
#else
#define stdc 0
#endif

output: RIGHT!
(Continue reading)

Permalink | Reply | 4 comments |
headers
David Beazley | 1 Jan 2004 03:30
Favicon

Preprocessor bug

skaller writes:
 > 
 > however, it works. Looking at the preprocessor now,
 > but its a hand tailored state machine...someone
 > else might find this before I can ..
 > 

I will fix this as long as there is a very specific example that
illustrates broken behavior.

-- Dave
Permalink | Reply | 3 comments |
headers
skaller | 1 Jan 2004 04:38
Picon
Picon

Re: Preprocessor bug: PATCH

On Thu, 2004-01-01 at 13:30, David Beazley wrote:
> skaller writes:
>  > 
>  > however, it works. Looking at the preprocessor now,
>  > but its a hand tailored state machine...someone
>  > else might find this before I can ..
>  > 
> 
> I will fix this as long as there is a very specific example that
> illustrates broken behavior.
> 

Given in previous email. Here is a patch that fixes it.
The problem was in getting a value, it said:

'write character'
'if its a slosh goto state 44'

.. after the \ was written. This is correct
UNLESS the next character is a newline.

I changed it so state 44 handles slosh correctly,
if the next char is newline both slosh and newline
are ignored and we go back to state 43.

Otherwise the slosh and next char are put in the value,
and we go back to state 43. Not sure if the increment
of the line count is correct.

------------PATCH HERE------------------------
(Continue reading)

Permalink | Reply | 0 comments |
headers
skaller | 1 Jan 2004 05:10
Picon
Picon

Re: Preprocessor bug

On Thu, 2004-01-01 at 13:30, David Beazley wrote:
> skaller writes:
>  > 
>  > however, it works. Looking at the preprocessor now,
>  > but its a hand tailored state machine...someone
>  > else might find this before I can ..
>  > 
> 
> I will fix this as long as there is a very specific example that
> illustrates broken behavior.

BTW: I don't understand this comment. The message you
are quoting in fact provided exactly what you ask for.

Here it is again.. the wrapper generated by the two
inputs fragments differs but shouldn't. 

Note we're talking about wrapping the define 'stdc'. 
The correct value is 1. 

The output generated happens to be output from
the Felix language module, and only a single line
of it at that. But it indicates the wrong value
is calculated because the wrong branch of the
conditional is taken by the preprocessor because
it evaluates the conditional incorrectly because
it doesn't process the trailing \ correctly.

I'm sure you can get the same behaviour from the Python
language module.
(Continue reading)

Permalink | Reply | 1 comment |
headers
David Beazley | 1 Jan 2004 05:18
Favicon

Re: Preprocessor bug

skaller writes:
 > 
 > Still the usual problem that C programmers always think
 > they own the world, shouldn't follow standards, and should
 > use macros everywhere possible for everything possible.

Macros are the best feature of C ;-).  On that note, thanks for the
patch.  I'll look at it more when I get back from vacation.

-- Dave
Permalink | Reply | 0 comments |
headers
skaller | 1 Jan 2004 05:34
Picon
Picon

Goals

I'd like to ask about/discuss SWIG goals,
specifically about support for processing C headers.

First I need to provide some motivation/background.

There are two ways to build a wrapper:

(a) from a hand written interface file

(b) from an interface file PLUS the original C header

There are advantages and disadvantages to both techniques.

(1) If a developer adds or changes interfaces to a library,
method (a) will break for sure. Method (b) might
also break due to the 'patching' done in the interface
file, but generally this technique is more robust
in the face of library changes.

(2) A large set of libraries differ across platforms.
Typically autoconf et al is used to configure a version
for your platform. Given this, certain details of
a handwritten interface file are guarranteed to be
wrong on some platforms. For example a typedef for
a platform specific type cannot be encoded in 
a handwritten file, at least without duplicating
all the autoconfiguration stuff. Clearly method
(b) is superior here.

(3) Unfortunately, the location of platform specific
(Continue reading)

Permalink | Reply | 1 comment |
headers
David Beazley | 2 Jan 2004 14:25
Favicon

Goals

skaller writes:
 > 
 > There are two ways to build a wrapper:
 > 
 > (a) from a hand written interface file
 > 
 > (b) from an interface file PLUS the original C header
 > 

[ snip ]
 > 
 > *** the swig directives aren't strong enough to handle
 > many situations ***
 > 

They work perfectly fine for me (and apparently a lot of other
people), so you're going to have to elaborate.

 > This is the point I would like to discuss in the light
 > of the question: do we really WANT to be able to
 > support method (b)?
 > 

I may be missing something, but SWIG has always supported a mix of (a) 
and (b) with the implicit understanding that (b) might not work if you 
give SWIG something that's really hairy.   I don't have a religious
attachment to either approach and tend to use a mix of them myself.

 > However, the amount of work for a language like Python
 > is different to Felix. For Python, you need a lot
(Continue reading)

Permalink | Reply | 0 comments |
headers
skaller | 3 Jan 2004 07:24
Picon
Favicon

Goals

[Excuse some misquoting, had to copy from archive
since my email account has just been killed]

-------------------
skaller writes:
 > 
 > There are two ways to build a wrapper:
 > 
 > (a) from a hand written interface file
 > 
 > (b) from an interface file PLUS the original C header
 > 

[ snip ]
 > 
 > *** the swig directives aren't strong enough to handle
 > many situations ***
 > 

They work perfectly fine for me (and apparently a lot of other
people), so you're going to have to elaborate.
-----------------------------------

Indeed ... though I think you'll probably
agree 'perfectly fine' is a bit strong.
You can't handle callbacks for example ..
I mean, why keep developing SWIG if it is
already perfect? :-))

-----------------------------------
(Continue reading)

Permalink | Reply | 0 comments |
headers
SourceForge.net | 6 Jan 2004 21:02
Picon
Favicon

[ swig-Bugs-871894 ] simple namespace problem

Bugs item #871894, was opened at 2004-01-06 12:02
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101645&aid=871894&group_id=1645

Category: code generation (general)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: David M. Beazley (beazley)
Summary: simple namespace problem

Initial Comment:
Consider the following definitions:

namespace ns {

    struct S1
    {
        int n;
    };

    typedef struct
    {
        int n;
    } S2;

}
(Continue reading)

Permalink | Reply | 0 comments |
headers
SourceForge.net | 4 Jan 2004 08:34
Picon
Favicon

[ swig-Bugs-870264 ] Problem compiling tests for swig 1.3.20

Bugs item #870264, was opened at 2004-01-04 08:34
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101645&aid=870264&group_id=1645

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Pierre (pierre42)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem compiling tests for swig 1.3.20

Initial Comment:
Hi,

I just compiled SWIG 1.3.20 without problem.
But when doing a "make check" I got this error :

[...]
checking Examples/ocaml/string_from_ptr
checking Examples/php4/class
gmake[1]: *** No rule to make target `check'.
checking Examples/php4/constants
gmake[1]: *** No rule to make target `check'.
checking Examples/php4/enum
gmake[1]: *** No rule to make target `check'.
checking Examples/php4/funcptr
gmake[1]: *** No rule to make target `check'.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane