469,292 Members | 1,417 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,292 developers. It's quick & easy.

problem with latest platform SDK and intrin.h

I am using the current platform SDK headers and libraries (including the
CRT headers and static CRT libraries). If I #include windows.h and intrin.h
in the same source file, the compiler spits out error C2733: second C
linkage of overloaded function '_interlockedbittestandset' not allowed
(doesn't matter if I #include intrin.h or windows.h first).
It doesn't happen if I use the header files and libraries that come with
Visual C++ 2005 pro.
Does anyone know why this is and what I can do about it?
Jun 2 '07 #1
4 10153
"Jonathan Wilson" <jf*****@tpgi.com.auwrote in message
news:Ox**************@TK2MSFTNGP02.phx.gbl...
>I am using the current platform SDK headers and libraries (including the
CRT headers and static CRT libraries). If I #include windows.h and intrin.h
in the same source file, the compiler spits out error C2733: second C
linkage of overloaded function '_interlockedbittestandset' not allowed
(doesn't matter if I #include intrin.h or windows.h first).
It doesn't happen if I use the header files and libraries that come with
Visual C++ 2005 pro.
Does anyone know why this is and what I can do about it?

There are 2 conflicting declarations of _interlockedbittestandset.

In intrin.h the first argument is long *
In WinNT.h the first argument is long volatile *

I'm not sure which declaration is correct but my solution was to edit
intrin.h and add the volatile keyword.

Jun 2 '07 #2
"Tom Walker" <no****@nowhere.comwrote in message
news:O5**************@TK2MSFTNGP05.phx.gbl...
"Jonathan Wilson" <jf*****@tpgi.com.auwrote in message
news:Ox**************@TK2MSFTNGP02.phx.gbl...
>>I am using the current platform SDK headers and libraries (including the
CRT headers and static CRT libraries). If I #include windows.h and
intrin.h in the same source file, the compiler spits out error C2733:
second C linkage of overloaded function '_interlockedbittestandset' not
allowed (doesn't matter if I #include intrin.h or windows.h first). It
doesn't happen if I use the header files and libraries that come with
Visual C++ 2005 pro.
Does anyone know why this is and what I can do about it?


There are 2 conflicting declarations of _interlockedbittestandset.

In intrin.h the first argument is long *
In WinNT.h the first argument is long volatile *

I'm not sure which declaration is correct but my solution was to edit
intrin.h and add the volatile keyword.
To me the C++ standard says there was no collision. Page 214, last
paragraph:
* Only the const and volatile type-specifiers at the outermost level of the
* parameter type specification are ignored in this fashion; const and
* volatile type-specifiers buried within a parameter type specification are
* significant and can be used to distinguish overloaded function
* declarations.

Jun 4 '07 #3
Norman Diamond wrote:
"Tom Walker" <no****@nowhere.comwrote in message
news:O5**************@TK2MSFTNGP05.phx.gbl...
>"Jonathan Wilson" <jf*****@tpgi.com.auwrote in message
news:Ox**************@TK2MSFTNGP02.phx.gbl...
>>I am using the current platform SDK headers and libraries
(including the CRT headers and static CRT libraries). If I #include
windows.h and intrin.h in the same source file, the compiler spits
out error C2733: second C linkage of overloaded function
'_interlockedbittestandset' not allowed (doesn't matter if I
#include intrin.h or windows.h first). It doesn't happen if I use
the header files and libraries that come with Visual C++ 2005 pro.
Does anyone know why this is and what I can do about it?


There are 2 conflicting declarations of _interlockedbittestandset.

In intrin.h the first argument is long *
In WinNT.h the first argument is long volatile *

I'm not sure which declaration is correct but my solution was to edit
intrin.h and add the volatile keyword.

To me the C++ standard says there was no collision. Page 214, last
paragraph:
* Only the const and volatile type-specifiers at the outermost level
of the * parameter type specification are ignored in this fashion; const
and
* volatile type-specifiers buried within a parameter type
specification are * significant and can be used to distinguish overloaded
function
* declarations.
The outermost level would be the difference between long * and long *
voliatile. In this case, the difference is between long volatile * and long
*, so the cv-qualifier is buried inside the declared type and does make a
difference. The compiler is complaining that since the function has C
linkage, it can't have two different overloads that differ only by CV
qualifiers as those are two separate function definitions s for C++, but a
single function definition for C.

-cd
Jun 4 '07 #4
"Carl Daniel [VC++ MVP]" <cp*****************************@mvps.org.nospam >
wrote in message news:uk**************@TK2MSFTNGP05.phx.gbl...
Norman Diamond wrote:
>"Tom Walker" <no****@nowhere.comwrote in message
news:O5**************@TK2MSFTNGP05.phx.gbl...
>>"Jonathan Wilson" <jf*****@tpgi.com.auwrote in message
news:Ox**************@TK2MSFTNGP02.phx.gbl...
I am using the current platform SDK headers and libraries (including
the CRT headers and static CRT libraries). If I #include windows.h and
intrin.h in the same source file, the compiler spits out error C2733:
second C linkage of overloaded function '_interlockedbittestandset' not
allowed (doesn't matter if I #include intrin.h or windows.h first). It
doesn't happen if I use the header files and libraries that come with
Visual C++ 2005 pro. Does anyone know why this is and what I can do
about it?

There are 2 conflicting declarations of _interlockedbittestandset.

In intrin.h the first argument is long *
In WinNT.h the first argument is long volatile *

I'm not sure which declaration is correct but my solution was to edit
intrin.h and add the volatile keyword.

To me the C++ standard says there was no collision. Page 214, last
paragraph:
* Only the const and volatile type-specifiers at the outermost level
* of the parameter type specification are ignored in this fashion; const
* and volatile type-specifiers buried within a parameter type
* specification are significant and can be used to distinguish
* overloaded function declarations.

The outermost level would be the difference between long * and long *
voliatile. In this case, the difference is between long volatile * and
long *, so the cv-qualifier is buried inside the declared type and does
make a difference.
OK, you agreed with me on that part of it, so you wasted time agreeing with
me before explaining why that part of it was irrelevant. Now just for
clarification, I'll agree with you on the part that seems to be relevant:
The compiler is complaining that since the function has C linkage, it
can't have two different overloads that differ only by CV qualifiers as
those are two separate function definitions s for C++, but a single
function definition for C.

-cd
OK yes, with C linkage that looks like a collision. With C linkage nearly
any kind of overload would be a collision.

Now where did I read rumours that Microsoft had started doing some
dogfooding again...

Jun 4 '07 #5

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

1 post views Thread by Matej Kenda | last post: by
12 posts views Thread by P. Adhia | last post: by
6 posts views Thread by Edd Dawson | last post: by
2 posts views Thread by Marek Suski | last post: by
16 posts views Thread by Eigenvector | last post: by
1 post views Thread by swethak | last post: by
reply views Thread by zhoujie | last post: by
reply views Thread by suresh191 | last post: by
reply views Thread by harlem98 | last post: by
1 post views Thread by Geralt96 | last post: by
reply views Thread by harlem98 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.