Error c2169 intrinsic function cannot be defined

Answers

• Yes, that pragma is fighting a losing battle.  The missing support for __asm in x64 code makes its future look very bleak.  It can’t be a real problem, you can give your function any name other than _inp().  You are supposed to, identifiers with leading underscores are reserved to the vendor.  The Express edition uses the same version of the compiler as the retail edition.

  ---

  Hans Passant.

  • Marked as answer by

    Monday, July 27, 2009 2:52 AM

So, I’ve dutifully not (for once) coded «using namespace std;» and I’ve dutifully (for once) stuck «std::» in front of a standard library routine so as not to have an accidental name clash with one of my own functions.

So, which square root function will run from main() and why?

1
2
3
4
5
6
7
8
9
10
11
12
13

#include <iostream>
#include <cmath>

double sqrt( double x )
{
   std::cout << "Go away, I'm gonna run my own function on " << x << " if I want to!  ";
   return -999999;
}

int main()
{
   std::cout << "The square root of 4 is ... " << std::sqrt( 4.0 ) << 'n';
}

(If your compiler complains then you can make the function definition
double sqrt( double x ) throw()
It doesn’t change the outcome.)

Technically the result is unspecified; see https://timsong-cpp.github.io/cppwp/n4659/headers#4

It so happens that the implementation(s) you’ve tried it on have

<cmath>

work as if:

1
2
3
4

#include <math.h>
namespace std {
  using sqrt = ::sqrt;
}

…which of course explicit, proper use of

std::

qualifiers won’t save you from, since you’ve just provided a definition of

::sqrt

that matches the declaration provided in

<math.h>

.

So, simply prepending std:: won’t save me from name clashes — I would explicitly have to put my own functions in their own namespaces? That is almost never done in this forum (although I suspect it would be done at work).

I tried it on quite a few implentations … all with the same result.

The issue arose from a std::sin() function used in a different thread.

I had to follow down several layers of includes to get to the declaration of sqrt(long double). This and the overloads seem to be declared globally and then injected into the std:: namespace, so I assume the complier is just matching the definition provided with the declaration (global via the std:: injection).

I believe the standard say something about «It is unspecified whether these names are first declared within the global namespace scope and are then injected into namespace std.»

Well for the original code, it uses the local def of sqrt() on VS. With VS, AFAIK the c-library functions are defined in :: if <xxx.h> is used and in :: and std:: if <cxxx> is used (pointing to the same :: function). In this case the local function ‘overrides’ the :: one which is the one used by std:: — hence std::sqrt() in this case calls the local version.

If you don’t want the local version to be used but the std:: (or standard ::) one, then you need to put your function in a namespace. Then :: or std:: will call the standard library version and to use your own, you need to call the one in the namespace.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

#include <iostream>
#include <cmath>

//namespace qqq {
	double sqrt(double x)
	{
		std::cout << "Go away, I'm gonna run my own function on " << x << " if I want to!  ";
		return -999999;
	}
//}

int main()
{
	std::cout << "The square root of 4 is ..." << std::sqrt(4.0) << 'n';
}

Calls the local one:

The square root of 4 is ...Go away, I'm gonna run my own function on 4 if I want to!  -999999

but by using a namespace for the local one, it calls the c-library version:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

#include <iostream>
#include <cmath>

namespace qqq {
	double sqrt(double x)
	{
		std::cout << "Go away, I'm gonna run my own function on " << x << " if I want to!  ";
		return -999999;
	}
}

int main()
{
	std::cout << "The square root of 4 is ..." << std::sqrt(4.0) << 'n';
}

The square root of 4 is ...2

I totally agree, @seeplus!

However, putting one’s own functions in their own namespace doesn’t get done in this forum. The advice is just «prepend std:: and all will be well».

People overloading sqrt/sin also doesn’t normally come up in this forum. What you demonstrated is going to be a problem regardless of «using namespace std» when dealing with most C library functions. I’ll usually just tell beginners to not put it in a header file; don’t care when people use it in individual files.

Perhaps a sentence could be added to https://isocpp.org/wiki/faq/coding-standards#using-namespace-std to say «use your own custom namespaces to prevent function overload ambiguities».

For me VS2019 spits out two errors with the original code:

line 5, «C2169 ‘sqrt’: intrinsic function, cannot be defined»
line 12, «C2264 ‘sqrt’: error in function definition or declaration; function not called»

Remove/comment out the <cmath> header and the errors still barf up. <iostream> includes other headers?

Enclose the custom sqrt function in a custom namespace and VS2019 has no complaint. Even without <cmath> std::sqrt is called.

Curiouser and curiouser….

The original code compiles just fine using Code::Blocks with MinGW-W64 8.1.0. Calling std::sqrt calls the custom function.

Custom namespace for custom function and the C sqrt is called.

Really curiouser and curiouser.

hmm, my VS2019 just gives a warning (C28251: Inconsistent annotation for function: this instance has an error) on the original code. 🤷‍♂️

Edit: Release gives me the errors…

I normally don’t compile code samples like this in debug mode, only release. Lazy, I guess. I never thought to try debug mode. *shrug*

Interesting VS2019 has «relaxed standards» with debug mode vs. release mode.

Maybe I should start using both modes. This example code shows there can be very different results.

With VS2019, release, warning level 4, x64, I get no errors/warnings!

But intellisense suggests warning C28251 for the sqrt function definition.

C28251: Inconsistent annotation for ‘sqrt’. This instance has no annotations.

Inconsistent annotation for function

Oh, ICK! More SAL in the CRT with MS.

sqrt(double) definition in corecrt_math.h:
_Check_return_ _CRT_JIT_INTRINSIC double __cdecl sqrt(_In_ double _X);

About an intrinsic function with VS…

If a function is an intrinsic, the code for that function is usually inserted inline, avoiding the overhead of a function call and allowing highly efficient machine instructions to be emitted for that function.

https://docs.microsoft.com/en-us/cpp/intrinsics/compiler-intrinsics?view=msvc-160

Learn something new everyday.

If you didn’t include <cstring>, then the compiler doesn’t know anything about strlen().

Edit:
Nevermind, I was barking up the wrong tree. And apparently you DON’T have to include <cstring> for strlen.

Edit2:
I think you don’t run into any compilation errors because you never try to use the function.

on visual studio expression, with the code

#include

size_t strlen( const char* )
{
return 0;
}

I got: error C2169: ‘strlen’ : intrinsic function, cannot be defined

err that first line was #include windows.h

anyways! it’s really not a good idea, because if anyone else uses it, they would assume that they’re calling the library function and not the overloaded one.

Quote:Original post by skulldrudgery
If you didn’t include <cstring>, then the compiler doesn’t know anything about strlen().

I’m sure that what you said is incorrect. If you comment the function definition of strlen provided by the user, you can see that the compiler calls the default version of the function.

Quote:Original post by skulldrudgery
Edit:
Nevermind, I was barking up the wrong tree. And apparently you DON’T have to include <cstring> for strlen.

This is unrelated to inclusion.

Quote:Original post by skulldrudgery
Edit2:
I think you don’t run into any compilation errors because you never try to use the function.

Even if I use strlen(«Hello»); in main() body, the compiler still doesn’t give me any complaint.

It’s actually amusing.. Seems like a compiler bug to me.. I have tried compiling the bellow program with visual studio 2005 and got 1 error during first try of compilation.. But when tried compiling the same program a second time it passed with 0 warnings and 0 errors.

I don’t know if there’s anything special with standard libraries. I have always treaten them as ordinary additional libraries. To my current knowledge they should obey the ODR (One Definition Rule). Meaning that a non-static function can defined only once per program.

For my best knowledge it’s uncommon practice to override standard functions. Personally I would probably curse the programmer who would override standard functions and caused a bug on the way. Hunting such bugs can be very time concuming, especially when you expect something to work because it was made by the experts and was tested by huge amount of programmers(people that use standard libraries). Other than that, I advise you to stop working with C functions and move on to CPP, such as std::string class. Even though it’s bit bloated, it has more advantages over C functions.

#include <cstring>size_t  strlen(const char *){  return 0;}void main(){  strlen("123");}  Compiling...1.cppLinking...1.obj : error LNK2005: _strlen already defined in MSVCRTD.lib(MSVCR80D.dll)D:CPP ProjectsgdDebuggd.exe : fatal error LNK1169: one or more multiply defined symbols foundBuild log was saved at "file://d:CPP ProjectsgdDebugBuildLog.htm"gd - 2 error(s), 0 warning(s)========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

HTH,
Shimon

Quote:Original post by Anonymous Poster
anyways! it’s really not a good idea, because if anyone else uses it, they would assume that they’re calling the library function and not the overloaded one.

In some cases it wouldn’t matter as much. Such as if you just wanted to deal with null pointers as though they are empty strings in functions like strcmp(). I’m pretty sure most of the standard string functions throw an error or access violation.

But I still agree that a wrapper would be better.

I’m a bit confused here — surely if you include <cstring> with a properly standards-compliant C++ compiler, the library strlen would be in the std namespace so you would be free to declare another strlen in the global or your own namespace without a conflict?

Or does this not apply if it is included via <windows.h>?