Strange name mangling in imported class function

Schubert@discussions.microsoft.com Christian Schubert

unread,

Oct 15, 2008, 5:21:01 PM10/15/08

to

Hi,

I've run into a strange name mangling problem using VC++ 2005 and VC+ 2008.

A given class function (example)

virtual bool OnValueDecrement(CExtGridWnd & wndGrid,
LONG nColNo,LONG nRowNo,INT nColType,INT nRowType);

is being imported as

?OnValueDecrement@CExtGridCell@@UAE_NAAVCExtGridWnd@@JJHH@Z

The third party DLL I'm using here exports this function as

?OnValueDecrement@CExtGridCell@@UAE_NXZ

I suppose this is a compiler/switch issue. Any clues?

David Lowndes

unread,

Oct 16, 2008, 3:07:03 AM10/16/08

to

>I've run into a strange name mangling problem using VC++ 2005 and VC+ 2008.
>A given class function (example)
>
>virtual bool OnValueDecrement(CExtGridWnd & wndGrid,
>LONG nColNo,LONG nRowNo,INT nColType,INT nRowType);
>
>is being imported as
>
>?OnValueDecrement@CExtGridCell@@UAE_NAAVCExtGridWnd@@JJHH@Z
>
>The third party DLL I'm using here exports this function as
>
>?OnValueDecrement@CExtGridCell@@UAE_NXZ

There appears to be a mis-match between what you think the interface
is and what it is.

The undname utility shows:

Undecoration of :-
"?OnValueDecrement@CExtGridCell@@UAE_NAAVCExtGridWnd@@JJHH@Z"

is :- "public: virtual bool __thiscall
CExtGridCell::OnValueDecrement(class CExt
GridWnd &,long,long,int,int)"

Undecoration of :- "?OnValueDecrement@CExtGridCell@@UAE_NXZ"
is :- "public: virtual bool __thiscall
CExtGridCell::OnValueDecrement(void)"

Dave

Christian Schubert

unread,

Oct 16, 2008, 10:43:01 AM10/16/08

to

> There appears to be a mis-match between what you think the interface
> is and what it is.
>
> The undname utility shows:
>
> Undecoration of :-
> "?OnValueDecrement@CExtGridCell@@UAE_NAAVCExtGridWnd@@JJHH@Z"
>
> is :- "public: virtual bool __thiscall
> CExtGridCell::OnValueDecrement(class CExt
> GridWnd &,long,long,int,int)"
>
> Undecoration of :- "?OnValueDecrement@CExtGridCell@@UAE_NXZ"
> is :- "public: virtual bool __thiscall
> CExtGridCell::OnValueDecrement(void)"
>
> Dave
>

Dave,

thanks a lot for your answer. However I'm not sure what it means :-)
The point is that no matter what compiler/linker settings I'm using I can't
get my app to import this function as
"?OnValueDecrement@CExtGridCell@@UAE_NXZ". I wouldn't mind but I can't debug
it (unknown symbol).

In addition when I compile the third party DLL (sources are available) the
exported symbol is
"?OnValueDecrement@CExtGridCell@@UAE_NAAVCExtGridWnd@@JJHH@Z " ( as shown in
depends.exe). I'm using the makefile delivered with the source code.

Any clues?

Christian

David Lowndes

unread,

Oct 16, 2008, 11:01:26 AM10/16/08

to

>> There appears to be a mis-match between what you think the interface
>> is and what it is.
>>
>> The undname utility shows:
>>
>> Undecoration of :-
>> "?OnValueDecrement@CExtGridCell@@UAE_NAAVCExtGridWnd@@JJHH@Z"
>>
>> is :- "public: virtual bool __thiscall
>> CExtGridCell::OnValueDecrement(class CExt
>> GridWnd &,long,long,int,int)"
>>
>> Undecoration of :- "?OnValueDecrement@CExtGridCell@@UAE_NXZ"
>> is :- "public: virtual bool __thiscall
>> CExtGridCell::OnValueDecrement(void)"
>>
>

>thanks a lot for your answer. However I'm not sure what it means :-)

Christian,

From what you originally reported, you were apparently using the
function as:

CExtGridCell::OnValueDecrement(
class CExt GridWnd &,long,long,int,int)"

whereas the DLL exported it as:

CExtGridCell::OnValueDecrement(void)

However, from what you now say, things are reversed!

>The point is that no matter what compiler/linker settings I'm using I can't
>get my app to import this function as
>"?OnValueDecrement@CExtGridCell@@UAE_NXZ". I wouldn't mind but I can't debug
>it (unknown symbol).
>
>In addition when I compile the third party DLL (sources are available) the
>exported symbol is
>"?OnValueDecrement@CExtGridCell@@UAE_NAAVCExtGridWnd@@JJHH@Z " ( as shown in
>depends.exe). I'm using the makefile delivered with the source code.

... so I'm not sure where the mis-match is - other than you presumably
have conflicting definitions between the source used to build the DLL
and the header file you're using to reference the library from your
application.

Dave

Christian Schubert

unread,

Oct 21, 2008, 7:47:02 AM10/21/08

to

>
> Christian,
>
> From what you originally reported, you were apparently using the
> function as:
>
> CExtGridCell::OnValueDecrement(
> class CExt GridWnd &,long,long,int,int)"
>
> whereas the DLL exported it as:
>
> CExtGridCell::OnValueDecrement(void)
>
> However, from what you now say, things are reversed!
>
> >The point is that no matter what compiler/linker settings I'm using I can't
> >get my app to import this function as
> >"?OnValueDecrement@CExtGridCell@@UAE_NXZ". I wouldn't mind but I can't debug
> >it (unknown symbol).
> >
> >In addition when I compile the third party DLL (sources are available) the
> >exported symbol is
> >"?OnValueDecrement@CExtGridCell@@UAE_NAAVCExtGridWnd@@JJHH@Z " ( as shown in
> >depends.exe). I'm using the makefile delivered with the source code.
>

> .... so I'm not sure where the mis-match is - other than you presumably

> have conflicting definitions between the source used to build the DLL
> and the header file you're using to reference the library from your
> application.
>
> Dave
>

Dave,

in the header file the function is declared as

----------------------------------------

virtual bool OnValueDecrement(
CExtGridWnd & wndGrid,
LONG nColNo,
LONG nRowNo,
INT nColType,
INT nRowType
);

-------------------------------------

This matches the declaration you expected. This also explains the symbols
found in the DLL I compiled myself. It does not explain the symbols in the
precompiled third-party DLL :-(
Are there any compiler switches to modify the way VC decorates the exported
symbols? IMHO this kind of complex decoration is just a way to accomplish
some kind of runtime check...

Christian

David Lowndes

unread,

Oct 21, 2008, 9:04:33 AM10/21/08

to

>...it does not explain the symbols in the precompiled third-party DLL

I can only suggest that you ask the vendor of the library what the
problem is.

>Are there any compiler switches to modify the way VC decorates the exported
>symbols?

Things like __cdecl and __stdcall will affect the name, as well as
exporting names using .DEF files. See the topic titled "Decorated
Names" in MSDN for a little more information.

> IMHO this kind of complex decoration is just a way to accomplish
>some kind of runtime check...

Mangling serves to ensure that the linking is correct at build time,
not at run-time.

Dave

Joseph M. Newcomer

unread,

Oct 21, 2008, 9:43:31 AM10/21/08

to

One question that occurred to me: what version of the compiler was used to create the DLL,
and what version of the compiler is being used to call it? Could there be a difference in
how the name mangling is done between two compilers? In the case of third-party software,
was it even the Microsoft compiler?
joe

Joseph M. Newcomer [MVP]
email: newc...@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

Christian Schubert

unread,

Oct 21, 2008, 10:52:01 AM10/21/08

to

Hi Joe, Hi Dave,

yes I'm quite sure it was MSVC 8 since the DLL contains some ASCII traces.
I'm using VC8 as well. I guess that's not the problem.
__stdcall is uses as calling convention here. __cdecl and __fastcall make a
difference (already tried it) but I never get the same result as in the
precompiled DLL.
Looks like a DEF file was used in this case (for whatever reason) unless
someone's got another idea...

Christian