warnings in Visual studio when using swig for perl on c++

[lililevy]

Hello,

I'm building a Perl wrapper for some C++ code using Visual Studio.NET.
My code is generic and simple C++ code.

In building the wrapper, I get lots of compiler warnings,
mostly regarding conversions:

warning C4244: 'initializing' : conversion from '__w64 int' to 'I32',
possible loss of data
warning C4312: 'type cast' : conversion from 'IV' to 'void *' of
greater size
warning C4267: 'argument' : conversion from 'size_t' to 'I32', possible
loss of data

The code works, but it's never a good idea to ignore these, and besides
they don't make
for confidence-inspiring build output.

Are there SWIG or Visual Studio compiler options I need to set to keep
these warnings from happening and get a clean build? (#pragma
warningdisable: x) doesn't
count).

Thanks in advance for anyone's help.
Lily.

 

[Sisyphus]

Hello,

I'm building a Perl wrapper for some C++ code using Visual Studio.NET.
My code is generic and simple C++ code.

In building the wrapper, I get lots of compiler warnings,
mostly regarding conversions:

warning C4244: 'initializing' : conversion from '__w64 int' to 'I32',
possible loss of data
warning C4312: 'type cast' : conversion from 'IV' to 'void *' of
greater size
warning C4267: 'argument' : conversion from 'size_t' to 'I32', possible
loss of data

The code works, but it's never a good idea to ignore these, and besides
they don't make
for confidence-inspiring build output.

Are there SWIG or Visual Studio compiler options I need to set to keep
these warnings from happening and get a clean build? (#pragma
warningdisable: x) doesn't
count).

Not quite sure what you're after. If '__w64 int' is 8 bytes, and 'I32' is 4
bytes, then obviously it's quite possible that there will be "loss of data"
if a '__w64 int' gets converted to an 'I32'. Do you want to be warned of
that ... or not ?

One way of avoiding that particular warning is to simply not convert a
'__w64 int' to an 'I32' - but that would presumably involve rewriting the
C/C++ code that you're wrapping.

'cl /?' specifies the following 'warnings" flags:

/wd<n> disable warning n
/we<n> treat warning n as an error
/wo<n> issue warning n once
/w<l><n> set warning level 1-4 for n
/W<n> set warning level (default n=1)
/Wall enable all warnings
/Wp64 enable 64 bit porting warnings

I don't know if there's anything there that helps.
I don't *think* there will be any SWIG options that will help out - but
that's only a guess, and I'm a notoriously bad guesser

For help from the Visual Studio angle, comp.os.ms-windows.programmer.misc
might have some useful advice, if there's none forthcoming here.

Cheers,
Rob

 

[lililevy]

I was trying to understand why I get these warnings.
I can see that it involves Perl macros that use the I32 type

#define dAX I32 ax = MARK - PL_stack_base + 1
#define dITEMS I32 items = SP - MARK
#define dXSARGS \
dSP; dMARK; \
dAX; dITEMS

I think that the following explanation might solve the problem,
didn't try it yet:
[From Swig and Perl5:]

23.2.7 Compiling for 64-bit platforms
On platforms that support 64-bit applications (Solaris, Irix, etc.),
special care is required when building extension modules. On these
machines, 64-bit applications are compiled and linked using a different
set of compiler/linker options. In addition, it is not generally
possible to mix 32-bit and 64-bit code together in the same
application.
To utilize 64-bits, the Perl executable will need to be recompiled as a
64-bit application. In addition, all libraries, wrapper code, and every
other part of your application will need to be compiled for 64-bits. If
you plan to use other third-party extension modules, they will also
have to be recompiled as 64-bit extensions.
If you are wrapping commercial software for which you have no source
code, you will be forced to use the same linking standard as used by
that software. This may prevent the use of 64-bit extensions. It may
also introduce problems on platforms that support more than one linking
standard (e.g., -o32 and -n32 on Irix).

any thoughts regarding this are welcomed.
Lily.