Why not networking support?

[Keith Thompson]

In <[email protected]> "Mark A. Odell"

Yes.

A conforming freestanding implementation shall accept any strictly
conforming program in which the use of the features specified in
the library section ($4) is confined to the contents of the standard
headers <float.h>, <limits.h>, <stdarg.h>, and <stddef.h>.

The list is a bit longer in C99, but it's still restricted to headers
unrelated to the standard C library.

Dan, your point is correct, but I don't understand that last sentence.
What "headers unrelated to the standard C library" are you referring
to? Are you limiting the term "standard C library" to refer only to
library *functions*?

 

[Keith Thompson]

When someone starts splitting hairs, it's better to leave him play his
game alone.

Indeed.

 

[Mark McIntyre]

Why doesn't the standard library provide (at least basic)
networking facilities using TCP/IP ?

Because the vast majority of target systems have no concept of networking.
Most can't even implement such a memory intensive idea.

 

[Mark McIntyre]

Accepted wisdom aside, why /couldn't/ C (in a future incarnation) define
a 'networking' interface in the same flavour as it now provides a file
access interface?

if ((data = fopen("tcp:127.0.0.1:9","w")) != NULL)

This is possible right now, and requires no extensions to C whatsoever.
Consider either a windows UNC or an NFS-mounted drive.

You merely have to have an OS that understands the filename syntax. So go
ahead, knock yourself out, its got to be a winner!

 

[Keith Thompson]

Because the vast majority of target systems have no concept of networking.
Most can't even implement such a memory intensive idea.

I don't think that that alone is a good argument against TCP/IP
support. Systems that can't support networking because of memory
constraints probably can't support a filesystem either, and thus are
likely to have freestanding, rather than hosted, C implementations.
(I'm guessing that most hosted implementations could support sensibly
TCP/IP networking; I could be mistaken on that point.)

Having said that, there are other reasons why putting TCP/IP support
into the C standard isn't necessarily a good idea.

 

[Dan Pop]

Dan, your point is correct, but I don't understand that last sentence.
What "headers unrelated to the standard C library" are you referring
to? Are you limiting the term "standard C library" to refer only to
library *functions*?

This is what the standard itself is doing, in several places:

Previously translated translation units may be preserved
individually or in libraries.
....
8. All external object and function references are resolved.
Library components are linked to satisfy external references
to functions and objects not defined in the current
translation.

The standard headers may or may not contain information related to the
standard C library. The ones I'm talking about do not. It is a gross
abuse to call them library facilities, simply because they are documented
in the Library clause of the standard (it would have been pointless to
create a special clause for them). Some of them, like <limits.h> and
<float.h> are not even documented in the Library clause.

Dan

 

[Dan Pop]

I don't think that that alone is a good argument against TCP/IP
support. Systems that can't support networking because of memory
constraints probably can't support a filesystem either, and thus are
likely to have freestanding, rather than hosted, C implementations.
(I'm guessing that most hosted implementations could support sensibly
TCP/IP networking; I could be mistaken on that point.)

It doesn't matter: fopen() can always fail on a hosted implementation,
if it cannot satisfy the user request. The ultimate reason the C standard
doesn't support networking is that the C committee didn't bother to
include networking support in the C standard. There is NO other reason.

Compare with <time.h> facilities. A hosted implementation without real
time support can have time() and clock() always return -1 (converted to
the appropriate type). Likewise, network facilities on a hosted
implementation could always fail on a machine with no networking hardware
or currently disconnected from the network.

Dan