Always the same discussion. First somebody claims something is not portable
because it doesnt work on some arcane system. Then somebody else brings in
something from the current standard that doesnt work on that same system
either. And then the talk about hosted/freestanding starts.
So we have an easy fix then. Just add to the standard:
*networking support is not required under freestanding implementations*
This discussion is largely bullshit, because it basically revolves about how
various engineering standards should be physically decomposed into documents;
in other words, which way is the paper cut.
Fact is that on some given system, I can use the C compiler to write networking
code. That code is even portable to other systems that have the same
networking interface. I couldn't care less if it's in the language or not;
I have the entire API of the system at my disposal, and that makes up the
C-based dialect in which I can program that system.
To write my code, I make use of features described in ISO C, and library
features described some other documents.
When we say that networking should be in C, we are really saying that the
document which defines the language should be extended with additional chapters
about networking (perhaps identical to those which I already have in my system
documentation, or another ISO or IEEE standard).
But there is no point in doing this, because that stuff is already in another
document.
It's up to the system users and their vendors to negotiate what programming
interfaces they want in the system and its toolchain. They can do that without
having all of those interfaces crammed under the umbrella of a programming
language.
Sometimes there are competing implementations of some interface in the market.
Which interface should ``win'' and get to be in the language? Whose
multithreading interface should be in the language? Which graphical interface
library? Et cetera.
C and POSIX have common roots, yet are separate. The standard C library started
out on Unix, together with C. The POSIX and C standardization committees were
created at about the same time, and divided library features between
themselves. They had to decide things like that the stat function would go into
POSIX, wheras malloc would go into C. Then they went their separate ways.
One good reason was done is that C was already used on non-Unix systems, which
didn't have the entry points corresponding to the Unix library functions.
Implementing the POSIX library would involve operating system emulation.
Those chapters in the standard would have to be optional. A chapter of optional
features in a standard is precisely as good as a separate standard!
Another good reason is simply that if you have too much stuff in a programming
language (i.e. one single document) it becomes more cumbersome to maintain that
document. When it comes time to ratify the document, then all of the
subdocuments contained within it have to be ratified. A delay in ratifying any
of the subdocuments delays the entire document. The meetings about the
document will be larger because they will involve more people. Larger meetings
will be slower and less productive. This means that it will take longer to get
anything done. Maybe the working group will have to be broken into smaller
working groups, which will work only with their section of the document. But
this is precisely as good as having separate documents with separate ISO
numbers, and their own release schedule!
Even the distinction between a hosted and freestanding C implementation could
be captured by fragmenting C into two documents: a base document describing the
freestanding features, and an additional separate document describing the
library, declaration of main, different implementation limits etc.