Re: [Mingw-users] Can I use the MinGW runtime library in Visual Studio ?

[Tor L. <tm...@ik...>]

>> Which ones, exactly? You do know that open(), read() etc are available
>> in all the Microsoft C libraries?

> Ok, ok, I get it. I see people here are still annoyed by my attitude; I
> won't bother you with this any more ... :)

Don't be so easily upset; I simply asked for a specific example?

Getting annoyed by the person you are arguing with is the essence of a
lively discussion, isn't it? What would be the point in a discussion
if one just said "oh, yes, you can say that too, and it also is
perfectly right" all the time?

> Although I am not found of Microsoft either, I think there is an
> explanation for those different rules. ISO C well allows third-party
> libraries, which is what MFC and <windows.h> are, so the names defined
> there can stay as third-party.
>
> The mkdir, open, creat, fileno, ... functions, on the other hand are not
> provided by a third party library, they are provided by the library that
> comes with the compiler, which places them in the C run-time library
> (CRT).

Hmm, OK, I can following this reasoning yes, and it does make sense.
So I can take back my "Animal Farm" insinuation. One should apparently
think of it like this:

When writing a pure C89 program that includes only C89 headers and
links to no non-default libraries, one should be free to use any
identifier for one's own code without problems. So yeah, from that
point of view, it is correct to hide functions like open() and read(),
which after all a (naïve?) C programmer might use for his own code.
While a program that explicitly includes non-C89 headers and links
with additional libraries shouldn't be surprised then if those headers
declare stuff with random names.

> I do not think I still follow you here. I would definitely use the POSIX
> APIs in my application and just include the emulation layer when on
> Windows. What if I have one more emulation layer ?

One more thing you can not be entirely sure of? Too much complexity
involved if you need only the most basic thread functionality? (Read
the pthreads-win32 code, it has to do some complicated stuff to
support full pthread semantics. It's been a while, so I don't remember
the details.) But no big deal here, if it works fine for your code, by
all means use it.

--tml