/Wp64 and declaration/defintion mismatch 
Author Message
 /Wp64 and declaration/defintion mismatch

Is it possible to catch mismatched declaration and definitions with /Wp64?

E. g.

#ifdef _WIN64
typedef __int64 INT_PTR;
#else
typedef int __w64 INT_PTR;
#endif

struct Foo
{
 Foo( INT_PTR i );

Quote:
};

Foo::Foo( int )    // will be a compiler error for _WIN64
{

Quote:
}

The compiler does not generate a warning here with /W4 /Wp64.
Is there a way to find such mismatches with the 32-bit compiler?

I fear we have got plenty in our MMC Snapins.

tia
-hg



Sun, 20 Feb 2005 18:12:25 GMT  
 /Wp64 and declaration/defintion mismatch

Quote:
>Is it possible to catch mismatched declaration and definitions with /Wp64?

>#ifdef _WIN64
>typedef __int64 INT_PTR;
>#else
>typedef int __w64 INT_PTR;
>#endif

>struct Foo
>{
> Foo( INT_PTR i );
>};

>Foo::Foo( int )    // will be a compiler error for _WIN64
>{
>}

Is there anything wrong here? Do you actually get a compiler error
with the 64-bit compiler?

Dave
--
MVP VC++ FAQ: http://www.mvps.org/vcfaq



Mon, 28 Feb 2005 16:19:30 GMT  
 /Wp64 and declaration/defintion mismatch
Dave,

inline

Quote:
> >Is it possible to catch mismatched declaration and definitions with
/Wp64?

> >#ifdef _WIN64
> >typedef __int64 INT_PTR;
> >#else
> >typedef int __w64 INT_PTR;
> >#endif

> >struct Foo
> >{
> > Foo( INT_PTR i );

translates to Foo( __int64 i );
Quote:
> >};

> >Foo::Foo( int )    // will be a compiler error for _WIN64

not declared for _WIN64
Quote:
> >{
> >}

> Is there anything wrong here? Do you actually get a compiler error
> with the 64-bit compiler?

Yep:

T.cpp(13) : error C2511: 'Foo::Foo(int)' :
    overloaded member function not found in 'Foo'
        T.cpp(8) : see declaration of 'Foo'

I first thought only the linker will complain but obviously you cannot
define a member function that has not been declared.

It is quite a pain to use the 64-bit compiler because some of the libs
we rely on are not yet available for Win64.

Any ideas?

tia
-hg



Mon, 28 Feb 2005 18:47:15 GMT  
 /Wp64 and declaration/defintion mismatch

Quote:
>Any ideas?

Not yet. I'll see what else I can find out.

Dave
--
MVP VC++ FAQ: http://www.mvps.org/vcfaq



Mon, 28 Feb 2005 19:22:04 GMT  
 /Wp64 and declaration/defintion mismatch

Quote:

> The compiler does not generate a warning here with /W4 /Wp64.
> Is there a way to find such mismatches with the 32-bit compiler?

Hello Holger,
  You can find the mismatch by compiling with the macro _WIN64 defined.  The
mismatch is tantamount to writing code like the following:

    #ifdef X
    typedef P TYPE;
    #else
    typedef Q TYPE;
    #endif
    // Note that P and Q are different classes

    struct C {
      void f(TYPE x);
    };

    void C::f(P x) { ... }

Under different macro definitions, the code has clearly different meanings.
/Wp64 would not have been able to diagnose this problem, as both int and
__int64 are very different types.  The __w64 modifier doesn't actually turn
int into an __int64 type -- it just makes the compiler do extra work at
assignments to see if there might be truncation leading to portability
errors.

Cheerio!

--
Brandon Bray                                          Visual C++ Compiler
This posting is provided AS IS with no warranties, and confers no rights.



Tue, 01 Mar 2005 04:52:42 GMT  
 /Wp64 and declaration/defintion mismatch
Thanks Brandon,

below

Quote:
>   You can find the mismatch by compiling with the macro _WIN64 defined.
The
> mismatch is tantamount to writing code like the following:

>     #ifdef X
>     typedef P TYPE;
>     #else
>     typedef Q TYPE;
>     #endif
>     // Note that P and Q are different classes

>     struct C {
>       void f(TYPE x);
>     };

>     void C::f(P x) { ... }

> Under different macro definitions, the code has clearly different

meanings.

Ok. But compiling with a 32-bit compiler and _WIN64 defined will likely
make things worse. At least I fail too see why it is better than the 64-bit
compiler.

Quote:
> /Wp64 would not have been able to diagnose this problem, as both int and
> __int64 are very different types.  The __w64 modifier doesn't actually
turn
> int into an __int64 type -- it just makes the compiler do extra work at
> assignments to see if there might be truncation leading to portability
> errors.

But the compiler could (easily?) emit a warning if types have different
__w64
qualification. If I understand correctly you say a int __w64 will not
neccessarily
be a __int64 in Win64. But it will obviously not be a int or the whole __w64
thing would be meaningless.
So when the compiler compares types ( e.g. for declaration/definition
matching,
template specialization ...) it should be possible to check the __w64
qualification of both when compiling with /Wp64.

Nevertheless it seems the best option is getting our libs ready and using
the
64-bit compiler.

Thanks anyway

Cheerio!
-hg



Tue, 01 Mar 2005 21:59:36 GMT  
 /Wp64 and declaration/defintion mismatch

Quote:

> But the compiler could (easily?) emit a warning if types have different
> __w64 qualification.

Hello Holger,
  It is true that the compiler could detect this mismatch, unfortunately it
is one of those low priority issues that is not going to be fixed for quite
a while.

Quote:
> If I understand correctly you say a int __w64 will not neccessarily be a
> __int64 in Win64.

That is correct.  __w64 is just a modifier to the x86 compiler to check a
few extra scenarios (like conversions between int and int __w64).  As far as
code generation goes, "int" and "int __w64" have the same meaning on x86 and
64-bit, as an int has only 4-bytes in both places.  It's definitely useful
if you use cast a pointer to an int for use as a handle or something like
that, as pointers have different sizes on both platforms.

Quote:
> ... it should be possible to check the __w64 qualification of both when
> compiling with /Wp64.

It is possible, but not anytime soon.

Quote:
> Nevertheless it seems the best option is getting our libs ready and using
> the 64-bit compiler.

That is certainly the fool-proof thing to do.  /Wp64 will help find 'some'
issues, but compiling in both environments is the best way to go.  We're
looking into ways of making the 64-bit cross-compiler easier to use from the
IDE at some point in the future.

Cheerio!

--
Brandon Bray                                          Visual C++ Compiler
This posting is provided AS IS with no warranties, and confers no rights.



Wed, 02 Mar 2005 03:28:35 GMT  
 /Wp64 and declaration/defintion mismatch
Hello Brandon,

Quote:
>   It is true that the compiler could detect this mismatch, unfortunately
it
> is one of those low priority issues that is not going to be fixed for
quite
> a while.

When the projects can be compiled with the 64-bit version from within the
IDE it will the better choice anyway.

Quote:
> > Nevertheless it seems the best option is getting our libs ready and
using
> > the 64-bit compiler.

> That is certainly the fool-proof thing to do.  /Wp64 will help find 'some'
> issues, but compiling in both environments is the best way to go.  We're
> looking into ways of making the 64-bit cross-compiler easier to use from
the
> IDE at some point in the future.

I finally set up a batch file to build the project with the Win64 SDK
compiler.
BTW: How do you build a solution configuration with a space in its name from
the command line?

Unfortunately this version (13.10.2154.8) seems to be more conformant
than the VC 7 version.
I'm seeing a whole bunch of errors for ATL::ChTraitsOS<wchar_t> because
it uses the generic template argument (_CharType) in an explicit
specialization.

Same thing for CElementTraits< GUID >.

I have created a new directory with the fixed versions and prepended it to
the
include env variable.

Compilation works fine so far. But linking fails because there is no Win64
version of atls.lib. How do you build atls(d).lib?

Thanks again Brandon

Cheerio!
-hg



Wed, 02 Mar 2005 07:46:01 GMT  
 /Wp64 and declaration/defintion mismatch
Oops, I did not see the readme.txt file in the SRC directory (pass me
another beer MC).

Ok pulled in the qithunk.s and stdcallthunk.s files from the PSDK
(src/atl/atl21asm).
Now I can build atls.lib and atlsd.lib.

But for atlmincrt cl.exe generates errors (/WX) because of a mismatch of
__declspec(restrict) and __declspec(noalias) qualifiers for some CRT memory
functions.

Compilation succeeds if I add the corresponding qualifiers to atlinit.cpp.
What
are noalias and restrict __declspec's about?

Now comes the real problem:
linking fails because atldload.lib is missing. I fail to see how to build
it.

BTW:
I'm building with PSDK Build (3672):
NMAKE /F atlmfc.mak ATL PLATFORM=IA64 DEBUG=0

Any enlightment is greatly appreciated.

tia

Cheerio!
-hg



Sun, 06 Mar 2005 07:46:11 GMT  
 
 [ 9 post ] 

 Relevant Pages 

1. Struct defintion in Interface

2. New Defintion Needed

3. /Wp64 and sizeof int question

4. size_t and unsigned int conversion errors with /Wp64 switch

5. defining declarations vs. referencing declarations

6. C Declaration --> VB Declaration

7. ComboBox & Textbox Height mismatch

8. program database mismatch

9. std::mismatch

10. htons mismatch compile waring?

11. va_arg parameter mismatching

12. Type Mismatch in Structure Reference

 

 
Powered by phpBB® Forum Software