C++ can't find non-standard C functions in global namespace

Question

We have a fairly large C++ project which I am now in the process of moving to VS2010 and also updating a few libs along the way. So far everything builds just fine now, except I get (to me) quite weird errors where apparently a number of (edit: non-)standard C functions and symbols are not defined:

error C2039: 'strdup' : is not a member of '`global namespace''    ...\ACE_wrappers\ace\OS_NS_string.inl    222
...
error C2065: 'O_WRONLY' : undeclared identifier                    ...\ACE_wrappers\ace\OS_NS_unistd.inl    1057
...

This affects the following functions and symbols for me:

strdup      getcwd      O_WRONLY
putenv      swab        O_TRUNC
access      unlink      S_IFDIR
chdir       mkdir       S_IFREG
rmdir       tempnam     O_RDONLY
isascii

One part in the include file from ACE I experimented with was the strdup part which looks like this:

ACE_INLINE char *
ACE_OS::strdup (const char *s)
{
#  if (defined (ACE_LACKS_STRDUP) && !defined(ACE_STRDUP_EQUIVALENT)) \
  || defined (ACE_HAS_STRDUP_EMULATION)
  return ACE_OS::strdup_emulation (s);
#  elif defined (ACE_STRDUP_EQUIVALENT)
  return ACE_STRDUP_EQUIVALENT (s);
#  elif defined (ACE_HAS_NONCONST_STRDUP)
  return ::strdup (const_cast<char *> (s));
#else
  return ::strdup (s);
#  endif /* (ACE_LACKS_STRDUP && !ACE_STRDUP_EQUIVALENT) || ... */
}

There are loads of similar sections for other functions above and below, all of which compile just fine.

The path taken in my case is the last one, i.e. return ::strdup (s);. If I hit F12 on the ::strdup VS takes me to the declaration in string.h of the C standard library.

If I remove the namespace qualifier it builds, although IntelliSense tells me that it's now a recursive call so it probably won't work. If I change the namespace to std:: I get around 270 more errors, this time from several other projects. If I change the function to ::_strdup it builds. Including string.h as the very frst thing changes nothing.

(Nota bene: “it builds” refers to “this particular compiler error disappears at that location, but it still leaves the errors about the other functions, obviously.)

I'm a little at a loss here. I noticed that many larger libraries either build their own abstraction over the standard library or provide things that are not there by default and that was a point where ACE and ImageMagick already clashed (in both typedefing ssize_t but with incompatible definitions). Since we pull in quite a few libraries (I don't have an exact overview either, right now) this could well be another clash, caused by the wrong include order and similar things. This is also hinted at by the fact that the same includes from ACE apparantly work fine in other projects in the same solution.

Anyone have an idea what I could look for here at least? The build log with /showIncludes is just 24k lines so I don't exactly see many patterns there, except that string.h gets included way before the problematic ACE header.

And I wouldn't want to modify the library source code as that will only bite us again if we update to a newer version.

Shirker

In C++, it's officially <cstring>, not <string.h>. – Sarnen

You can use either and they differ in whether the functions appear in the global namespace and only maybe in std or whether they appear in std and only maybe in the global namespace. It doesn't make a difference there, though. At least that's how I understood it. – Shirker

@Sarnen - it's officially both <cstring> and <string.h>. <cstring> is required to put names into namespace std and <string.h> is required to put names into the global namespace. – Ednaedny

Did you try pre-processing the code only and verifying in the resultant output that the functions are in the global namespace (what if <string.h> got included within a namespace <blah> { by accident?) – Esta

Judging from google searches, ACE is supported on VS. Maybe your solution is missing some defines? Can you download the VS solution files from the original source? – Sangria

Mark B: Thanks a lot; I was hesitant to do so (preprocessed output is about the same fun to read as /showIncludes build output) but it pointed me in the right direction. – Shirker

Robᵩ: ACE itself builds just fine, as do all the other projects in the solution that include headers from it. The cause was that the project (solutions have no preprocessor symbols) defined an additional symbol. – Shirker

Answer 1

With Mark B's comment which prompted me to look at 12 MiB of Preprocessor output I was able to solve it. In string.h the snippet where strdup is defined looks like this:

#if     !__STDC__

...

_Check_return_ _CRT_NONSTDC_DEPRECATE(_strdup) _CRTIMP char * __cdecl strdup(_In_opt_z_ const char * _Src);

It so happened that this single project defines the __STDC__ symbol which causes a lot of non-standard-C-but-still-in-the-C-standard-library (thanks, Rob_φ for nitpicking but not solving the issue) functions to disappear completely.

I know they're deprecated, I got plenty of warnings that tell me so. But as noted, I'm not maintaining project-specific patches to 3rd-party libraries we use just to have the same fun all over again if we ever update them.

Shirker

Answer 2

"a number of standard C functions and symbols are not defined"

strdup is not a standard C function. It is defined in POSIX, but not in C or C++. Quoting MSDN:

These POSIX functions are deprecated beginning in Visual C++ 2005. Use the ISO C++ conformant _strdup, _wcsdup, _mbsdup instead.

It appears to me that none of the symbols you list are standard C functions.

Doxy

Ok, you're technically correct and pointed out part of the root cause but this did not help in any way in solving the issue. – Shirker

I've never seen the phrase "ISO C++ conformant" used to mean "made up by Microsoft" before. – Disturbed

@Mike Seymour It means that because they're in the global namespace and start with _ the compiler is allowed to use those names. – Esta

Answer 3

If I understand VS correctly, the strdup, etc. function names are deprecated nowadays (not POSIX compliant, I think). You should use the underlined versions.

When this happened for me, I ran a global search and replace, since it seemed like a sensible thing to do and keeps the source code in good condition for the future (VS 2012 is already out! :) ).

Illicit

Except that it's not me using them but another library. – Shirker