Why not networking support?

[H.A. Sujith]

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

[Dan Pop]

In <Pi************ *************** *******@unix42. andrew.cmu.edu> "Arthur J. O'Dwyer" <aj*@nospam.and rew.cmu.edu> writes:

On Tue, 13 Jul 2004, Lew Pitcher wrote:

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? The same caveats and exceptions for hosted vs unhosted
that currently apply to the stdio library could be applied to this
hypothetical stdnet library.
Probably because it wouldn't be useful (which AFAICT was Dan's original
point).

My point was directed towards the OP's request for TCP/IP support in
standard C. It doesn't apply to a generic networking interface, as
suggested by Lew.
If it only does TCP/IP, it's useless to people who want to use
other protocols, and if it only does the kind of "raw" communications
provided by the *nixy accept/bind/connect/listen paradigm, then, well,
people who program on those platforms *already* have that functionality
available, and don't need standard C to provide it.
And raw communications aren't generally useful anyway. What the
client programmer wants is a simple interface, like the "extended
fopen" you describe below. And that interface would have to imply
some kind of really-high-level protocol like, I dunno, HTTP or FTP
or something. Or one of the myriad P2P protocols about which I know
*really* nothing.
In short: Raw communications are too low-level to be an improvement
over OS calls, and high-level communications are too narrowly useful.

So, go for the intermediate level provided by TCP/IP: TCP or UDP level
connections instead of raw IP datagrams. UDP in binary mode and TCP in
text mode are the perfect building blocks for higher level protocols.
Many client applications only need a small subset of a complex higher
level protocol. To me, something only supporting a few high level
protocols would be next to useless, as, most of the time, I'm designing
and implementing my own (trivial) protocols, on top of UDP or TCP.

But this level of detail should be obviously left to the implementor, as
well as the choice of basic networking protocols supported.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Dan Pop]

In <cd**********@o ravannahka.hels inki.fi> Joona I Palaste <pa*****@cc.hel sinki.fi> writes:

Dan Pop <Da*****@cern.c h> scribbled the following:

In <Xn************ *************** *****@130.133.1 .4> "Mark A. Odell" <od*******@hotm ail.com> writes:

Joona I Palaste <pa*****@cc.hel sinki.fi> wrote in
news:cd***** *****@oravannah ka.helsinki.fi:
>>Why doesn't the standard library provide (at least basic)
>>networkin g facilities using TCP/IP ?

> Why TCP/IP?

> Instead of trying to answer my question, think about it. It's supposed
> to contain the answer to your question.

Umm... I know! I think. Can I answer for the OP?

Me too, I think because then someone would ask, "Why not DeviceNET" and
then we'd add that to C and next thing you know, C would only be able to
run on hosted implementations .

Freestanding implementations need not provide *any* of the standard C
library, so I fail to see your point. You were not thinking about TCP/IP
support in the C syntax, right?

I don't think he was. We don't have STDIO support in the C syntax
either, have we?

No, but freestanding implementations are free to completely ignore
<stdio.h>, so his point was valid ONLY if the networking support was
in the C syntax. Engage your goddam brain, or it will rust completely!

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[SM Ryan]

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

Because language standards should define the language and not everything
that could be done with the language. Unfortunately many people cannot
cope with a tessellation of standards and so they ended up demanding
monolithic standards including TCP/IP with C, or including I/O with C,
or including IEEE floating point with C, etc. There's already a number
of irrelevant issues in ANS C, like requiring integer arithmetic to be
modulo 2^n instead of letting the implementation define how to cope with
overflow.

--
SM Ryan http://www.rawbw.com/~wyrmwif/
This is one wacky game show.

[Keith Thompson]

SM Ryan <wy*****@tang o-sierra-oscar-foxtrot-tango.fake.org> writes:

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

Because language standards should define the language and not everything
that could be done with the language. Unfortunately many people cannot
cope with a tessellation of standards and so they ended up demanding
monolithic standards including TCP/IP with C, or including I/O with C,
or including IEEE floating point with C, etc. There's already a number
of irrelevant issues in ANS C, like requiring integer arithmetic to be
modulo 2^n instead of letting the implementation define how to cope with
overflow.

You mean unsigned integer arithmetic, right?

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Harti Brandt]

On Wed, 14 Jul 2004, Lew Pitcher wrote:

LP>-----BEGIN PGP SIGNED MESSAGE-----
LP>Hash: SHA1
LP>
LP>Dan Pop wrote:
LP>
LP>> In <MN************ ********@news20 .bellglobal.com > Lew Pitcher
LP><Le********* @td.com> writes:
LP>>
LP>>
LP>>>Accepted wisdom aside, why /couldn't/ C (in a future incarnation) define
LP>>>a 'networking' interface in the same flavour as it now provides a file
LP>>>access interface?
LP>>
LP>>
LP>> The most likely answer would be: lack of existing practice. So, if some
LP>> popular implementor does it, there are chances for it to become a
LP>> standard feature. Until then, we're in the good old "the egg and
LP>> the hen" deadlock ;-)
LP>
LP>That's an answer I can live with :-)
LP>
LP>Until some C implementation actually /implements/ this behaviour, we
LP>won't ever /see/ this behaviour.

You may want to look up a description of the portal filesystem under BSD.
(search on mount_portalfs on www.freebsd.org).

harti

LP>Perhaps we can convince PJP that Dinkumware /needs/ to implement
LP>networking within their stdio library <vbg>
LP>
LP>- --
LP>
LP>Lew Pitcher, IT Consultant, Enterprise Application Architecture
LP>Enterprise Technology Solutions, TD Bank Financial Group
LP>
LP>(Opinions expressed here are my own, not my employer's)
LP>-----BEGIN PGP SIGNATURE-----
LP>Version: GnuPG v1.2.4 (MingW32)
LP>
LP>iD8DBQFA9Wde agVFX4UWr64RAlw bAJ0eTfpv6pxmWK xQHTLDweNQTdbMm ACgv3Lt
LP>UYMI3MdTiGE8 Qmh3+2TwTCo=
LP>=UOUz
LP>-----END PGP SIGNATURE-----
LP>

[Mark A. Odell]

Ben Pfaff <bl*@cs.stanfor d.edu> wrote in news:87******** ****@benpfaff.o rg:

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

What does that mean to an 8-bit microcontroller with 128 bytes of RAM
and 8kB of ROM?

You are trying to say that there is an 8-bit microcontroller with
128 bytes of RAM, 8 kB of ROM, and a *hosted* implementation of
C? That'd be a sight to see.

No, I did not mean to imply such a case.

--
- Mark ->
--

[Mark A. Odell]

Da*****@cern.ch (Dan Pop) wrote in news:cd******** **@sunnews.cern .ch:

I don't think he was. We don't have STDIO support in the C syntax
either, have we?

No, but freestanding implementations are free to completely ignore
<stdio.h>, so his point was valid ONLY if the networking support was
in the C syntax.

Really. So can the compiler vendor claim ISO C compliance in such a case
yet not supply many of the stdio.h functions?
--
- Mark ->
--

[Dan Pop]

In <wF************ ********@news20 .bellglobal.com > Lew Pitcher <Le*********@td .com> writes:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dan Pop wrote:

In <40************ **@sun.com> Eric Sosman <Er*********@su n.com> writes:

Something like the above could be done without any
change at all to Standard C. The implementation, not the
Standard, defines how file name strings are formatted and
what they mean, and nothing's preventing an implementation

from recognizing "tcp:127.0.0.1: 9" as the designator for

a socket. (Or for a tuna salad sandwich, for that matter.)

But, if it's not required by the standard, you have no guarantee that
an implementation supports it all, so you cannot use it in portable code.

But, then again, when passed to fopen() as the filename parameter, the
string "c:\\windows\\s ystem32\\etc\\s ervices" isn't required by the
standard either, nor is "/etc/services", or even "DD:SYSIN". But, this
lack of standardization doesn't prevent the use of fopen() in portable code.

Because you can obtain the file name at run time, in various ways.
If you are willing to decry the interpretation of the fopen() 'filename'
"tcp:127.0.0.1: 9" as not being required by the standard, then you
probably should also decry "/etc/services" (or for that matter, just
"services") as well.

The point is that, unless the standard requires it, you cannot rely on
fopen() to be usable for network connections *at all*, no matter where
the "filename" comes from. If you don't believe me, try using fopen()
right now for this purpose and tell us on how many implementations your
network client worked.

So, you can rely on fopen() for opening a file,

Ahh, but what is a "file"?

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

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Dan Pop]

In <Xn************ *************** *****@130.133.1 .4> "Mark A. Odell" <od*******@hotm ail.com> writes:

Da*****@cern.c h (Dan Pop) wrote in news:cd******** **@sunnews.cern .ch:

I don't think he was. We don't have STDIO support in the C syntax
either, have we?

No, but freestanding implementations are free to completely ignore
<stdio.h>, so his point was valid ONLY if the networking support was
in the C syntax.

Really. So can the compiler vendor claim ISO C compliance in such a case
yet not supply many of the stdio.h functions?

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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Ben Pfaff]

"Mark A. Odell" <od*******@hotm ail.com> writes:

Ben Pfaff <bl*@cs.stanfor d.edu> wrote in news:87******** ****@benpfaff.o rg:

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

What does that mean to an 8-bit microcontroller with 128 bytes of RAM
and 8kB of ROM?

You are trying to say that there is an 8-bit microcontroller with
128 bytes of RAM, 8 kB of ROM, and a *hosted* implementation of
C? That'd be a sight to see.

No, I did not mean to imply such a case.

Then there's no point in using such an example to discount
anything being added to the standard *hosted* C library.
--
"Large amounts of money tend to quench any scruples I might be having."
-- Stephan Wilms