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

Question

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

Answer 1

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.