Why is getcwd() not ISO C++ compliant?

This MSDN article states that getcwd() has been deprecated and that开发者_Go百科 the ISO C++ compatible _getcwd should be used instead, which raises the question: what makes getcwd() not ISO-compliant?

There is a good discussion about that. P.J. Plauger answers to this

I'm the guy who insisted back in 1983 that the space of names available to a C program be partitioned into:

a) those defined by the implementation for the benefit of the programmer (such as printf)
b) those reserved to the programmer (such as foo)
c) those reserved to the implementation (such as _unlink)

We knew even then that "the implementation" was too monolithic -- often more than one source supplies bits of the implementation -- but that was the best we could do at the time. Standard C++ has introduced namespaces to help, but they have achieved only a fraction of their stated goals. (That's what happens when you standardize a paper tiger.)

In this particular case, Posix supplies a list of category (a) names (such as unlink) that you should get defined when and only when you include certain headers. Since the C Standard stole its headers from Unix, which is the same source as for Posix, some of those headers overlap historically. Nevertheless, compiler warnings should have some way of taking into account whether the supported environment is "pure" Standard C++ (a Platonic ideal) or a mixed C/C++/Posix environment. The current attempt by Microsoft to help us poor programmers fails to take that into account. It insists on treating unlink as a category (b) name, which is myopic.

Well, GCC will not declare POSIX names in strict C mode, at least (though, it still does in C++ mode):

#include <stdio.h>

int main() {
    &fdopen;
    return 0;
}

Output using -std=c99

test.c: In function 'main':
test.c:4: error: 'fdopen' undeclared (first use in this function)

You will have to tell it explicitly that you are operating in a mixed C/Posix by using feature test macros or not passing any specific standard. It will then default to gnu89 which assumes a mixed environment (man feature_test_macros). Apparently, MSVC does not have that possibility.

Functions not specified in the standard are supposed to be prefixed by an underscore as an indication that they're vendor-specific extensions or adhere to a non-ISO standard. Thus the "compliance" here was for Microsoft to add an underscore to the name of this specific function since it's not part of the ISO standard.

As others have already pointed out, getcwd is not included in ISO C++, but is part of POSIX/IEEE Std 1003.1.

Microsoft has decided to include some of the most commonly used POSIX functions in their C standard library (but prefix these functions with an underscore to essentially discourage their usage).

For the record, getcwd() wasn't deprecated by ISO. It was "deprecated" by Microsoft. Microsoft rewrote many C functions -- often with a little better security in mind (say, string functions that also take a max_length parameter). They then had their compiler spit out these warnings, which I consider bogus because no standards group deprecated any of the functions declared deprecated.

To add on to Dan Olson's post: See ANSI C Compliance page on MSDN

The names of Microsoft-specific functions and global variables begin with a single underscore. These names can be overridden only locally, within the scope of your code. For example, when you include Microsoft run-time header files, you can still locally override the Microsoft-specific function named _open by declaring a local variable of the same name. However, you cannot use this name for your own global function or global variable.

As far as I'm aware getcwd() has never been part of ISO Standard C++. _getcwd() definitely isn't, as standard names will not begin with an underscore.

In fact, the MSDN article links to a man page that says it is declared in direct.h, which is not a Standard C++ header file. The article seems bogus to me.

The MSDN article is somewhat confusing in what a normal person would conclude from just a quick reading (if they don't read it with a very careful lawyer eye).

What the MSDN article says is: getcwd() is not compliant with the ISO C++ standard. To comply with that ISO C++ standard for naming of functions (which is what getcwd violates), Microsoft properly put an _ on the front of the function, so the same function becomes _getcwd(). That is the ISO C++ compliant way of naming the function because getcwd() and _getcwd() are not an ISO C++ standard function, but are a Microsoft (vendor) specific, or implementation specific function.

The article does not indicate what a C++ ISO standard call to get the working directory would be... though thats what folks tend to read at a quick glance.