close vs _close, read vs _read, write vs _write - What is difference?

Question

I´m migrating a simple socket client program from Linux to Windows (VS2012). The program uses the regular close, read and write functions.

When compiling in VS2012, I´m getting the following warnings:

warning C4996: 'close': The POSIX name for this item is deprecated. Instead, use the ISO C++ conformant name: _close

warning C4996: 'write': The POSIX name for this item is deprecated. Instead, use the ISO C++ conformant name: _write

warning C4996: 'read': The POSIX name for this item is deprecated. Instead, use the ISO C++ conformant name: _read

The solution is simple - just to add the underscode - but...

What´s the real difference between close and _close, read and _read, write and _write ?

Just changing to the underscore version will preserve the same behaviour ?

Answer 1

When compiling in VS2012, I´m getting the following warnings

Wow, those are hilariously misleading messages. Good job, Microsoft.

They seem to suggest that _close, _read and _write are somehow ISO C++ functions.
They are not!

What's the real difference between close and _close, read and _read, write and _write ?

Microsoft has apparently reimplemented the POSIX functions close, read and write. The difference is that, when reimplementing, they've chosen to rename those functions with a leading underscore, because the ISO C++ standard says that a leading underscore is what the implementation (i.e. Visual Studio) should use for internal/built-in functions.

Just changing to the underscore version will preserve the same behaviour ?

I'm not going to enumerate the various potential differences here. As a matter of course, for full information on how those functions work and how to use them, read their documentation. The direct answer, though, is not to assume that the behaviour is the same as that of the similarly-named POSIX functions.

Answer 2

The error message is a political statement, not an actual truth.

Since _close is claimed to be "ISO C++ conformant", the insinuation is that the POSIX close naming is not ISO C++ conformant.

That is complete rubbish.

The names with underscores is simply how Microsoft has implemented an imitation of a subset of POSIX in their library, for decades. (With extensions, such as the _spawn* family of functions, which make up for the lack of fork).

The names are ISO C and C++ conforming in the sense that they are confined to a reserved namespace. If you, the programmer, uses an identifier like _close as an external name, then the behavior is undefined. But that doesn't mean it's a good idea for language implementors to use such identifiers for their public API's. They are useful for internal (perhaps undocumented) identifiers. Microsoft made a regrettable choice to create some API's with ugly names once upon a time, and later crafted a compiler error message to retroactively justify it.

But, look, the Windows API is chock full of identifiers which are not confined to the _[a-zA-Z0-9_]* namespace, such as CreateWindow, and WaitForSingleObject.

If close is not "ISO C++ conformant", then neither are these!

In fact ISO C and C++ allow implementors to have additional library functions with names in the ordinary namespace, such as close or WaitForSingleObject. A name like _close only conforms in the sense that no future ISO C or C++ standard will likely use it. But that's also true, practically speaking, of the identifiers of any major API, like POSIX or Windows.

If you're a minor player in the world of system API's, and you give a function some short name (that is, say, an English dictionary word) even if it doesn't clash with ISO C now, a future standard could run its proverbial bulldozer over it. There is no danger of that happening to the POSIX functions.