problem with latest platform SDK and intrin.h

  • Thread starter Thread starter Jonathan Wilson
  • Start date Start date
J

Jonathan Wilson

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?
 
Jonathan Wilson said:
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?
Click to expand...


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.
 
Tom Walker said:
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.
Click to expand...

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.
 
Norman said:
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.
Click to expand...

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
 
Carl Daniel said:
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.
Click to expand...

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
Click to expand...

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...
 
Back
Top