Why doesn't the standard library provide (at least basic)
networking facilities using TCP/IP ?
networking facilities using TCP/IP ?
-
-
Re: Why not networking support?
"H.A. Sujith" <sujith@localho st.localdomain> wrote in
news:slrncf7icc .2sr.sujith@loc alhost.localdom ain:
[color=blue]
> Why doesn't the standard library provide (at least basic)
> networking facilities using TCP/IP ?[/color]
What does that mean to an 8-bit microcontroller with 128 bytes of RAM and
8kB of ROM? C has been ported to all sorts of hardware, many that simply
could not easily fit even a simple TCP/IP stack. No, C should not be
burdened with networking.
--
- Mark ->
--
-
Re: Why not networking support?
On Tue, 13 Jul 2004 12:47:19 +0000, Mark A. Odell wrote:
[color=blue]
> "H.A. Sujith" <sujith@localho st.localdomain> wrote in
> news:slrncf7icc .2sr.sujith@loc alhost.localdom ain:
>[color=green]
>> Why doesn't the standard library provide (at least basic)
>> networking facilities using TCP/IP ?[/color]
>
> What does that mean to an 8-bit microcontroller with 128 bytes of RAM and
> 8kB of ROM? C has been ported to all sorts of hardware, many that simply
> could not easily fit even a simple TCP/IP stack. No, C should not be
> burdened with networking.[/color]
Humm, file access wouldn't make much sense on such systems either..
Anyway original poster should rather turn to the posix specifications.
Comment
-
Re: Why not networking support?
"H.A. Sujith" <sujith@localho st.localdomain> wrote:
[color=blue]
> Why doesn't the standard library provide (at least basic)
> networking facilities using TCP/IP ?[/color]
Because not nearly all networks are TCP/IP, and when C was first
standardised, even fewer were.
Richard
Comment
-
Re: Why not networking support?
In <slrncf7icc.2sr .sujith@localho st.localdomain> "H.A. Sujith" <sujith@localho st.localdomain> writes:
[color=blue]
>Why doesn't the standard library provide (at least basic)
>networking facilities using TCP/IP ?[/color]
Why TCP/IP?
Instead of trying to answer my question, think about it. It's supposed
to contain the answer to your question.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de
Comment
-
Re: Why not networking support?
Dan Pop <Dan.Pop@cern.c h> scribbled the following:[color=blue]
> In <slrncf7icc.2sr .sujith@localho st.localdomain> "H.A. Sujith" <sujith@localho st.localdomain> writes:[color=green]
>>Why doesn't the standard library provide (at least basic)
>>networking facilities using TCP/IP ?[/color][/color]
[color=blue]
> Why TCP/IP?[/color]
[color=blue]
> Instead of trying to answer my question, think about it. It's supposed
> to contain the answer to your question.[/color]
Umm... I know! I think. Can I answer for the OP?
--
/-- Joona Palaste (palaste@cc.hel sinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"The day Microsoft makes something that doesn't suck is probably the day they
start making vacuum cleaners."
- Ernst Jan Plugge
Comment
-
Re: Why not networking support?
Joona I Palaste <palaste@cc.hel sinki.fi> wrote in
news:cd17al$s1t $1@oravannahka. helsinki.fi:
[color=blue][color=green][color=darkred]
>>>Why doesn't the standard library provide (at least basic)
>>>networking facilities using TCP/IP ?[/color][/color]
>[color=green]
>> Why TCP/IP?[/color]
>[color=green]
>> Instead of trying to answer my question, think about it. It's supposed
>> to contain the answer to your question.[/color]
>
> Umm... I know! I think. Can I answer for the OP?[/color]
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 .
--
- Mark ->
--
Comment
-
Re: Why not networking support?
Mark A. Odell <odellmark@hotm ail.com> scribbled the following:[color=blue]
> Joona I Palaste <palaste@cc.hel sinki.fi> wrote in
> news:cd17al$s1t $1@oravannahka. helsinki.fi:[color=green][color=darkred]
>>>>Why doesn't the standard library provide (at least basic)
>>>>networkin g facilities using TCP/IP ?[/color]
>>[color=darkred]
>>> Why TCP/IP?[/color]
>>[color=darkred]
>>> Instead of trying to answer my question, think about it. It's supposed
>>> to contain the answer to your question.[/color]
>>
>> Umm... I know! I think. Can I answer for the OP?[/color][/color]
[color=blue]
> 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 .[/color]
You are right, but that's not what I was thinking about. Maybe I read
too much into Dan's emphasis on _TCP/IP_?
--
/-- Joona Palaste (palaste@cc.hel sinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"To doo bee doo bee doo."
- Frank Sinatra
Comment
-
Re: Why not networking support?
Joona I Palaste <palaste@cc.hel sinki.fi> wrote in
news:cd17ve$scc $1@oravannahka. helsinki.fi:
[color=blue][color=green][color=darkred]
>>>>>Why doesn't the standard library provide (at least basic)
>>>>>networki ng 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?[/color][/color]
>[color=green]
>> 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 .[/color]
>
> You are right, but that's not what I was thinking about. Maybe I read
> too much into Dan's emphasis on _TCP/IP_?[/color]
Are you saying that one might ask for built-in UDP support or heavens, raw
IP support? I can hear C getting fatter as we just discuss this.
--
- Mark ->
--
Comment
-
Re: Why not networking support?
Mark A. Odell <odellmark@hotm ail.com> scribbled the following:[color=blue]
> Joona I Palaste <palaste@cc.hel sinki.fi> wrote in
> news:cd17ve$scc $1@oravannahka. helsinki.fi:[color=green][color=darkred]
>>>>>>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?[/color]
>>[color=darkred]
>>> 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 .[/color]
>>
>> You are right, but that's not what I was thinking about. Maybe I read
>> too much into Dan's emphasis on _TCP/IP_?[/color][/color]
[color=blue]
> Are you saying that one might ask for built-in UDP support or heavens, raw
> IP support? I can hear C getting fatter as we just discuss this.[/color]
No, I would not be asking "what?" or "what not?" but instead "how?". But
maybe my answer won't make sense after all.
--
/-- Joona Palaste (palaste@cc.hel sinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"It sure is cool having money and chicks."
- Beavis and Butt-head
Comment
-
Re: Why not networking support?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Mark A. Odell wrote:[color=blue]
> Joona I Palaste <palaste@cc.hel sinki.fi> wrote in
> news:cd17al$s1t $1@oravannahka. helsinki.fi:
>
>[color=green][color=darkred]
>>>>Why doesn't the standard library provide (at least basic)
>>>>networkin g facilities using TCP/IP ?[/color]
>>[color=darkred]
>>>Why TCP/IP?[/color]
>>[color=darkred]
>>>Instead of trying to answer my question, think about it. It's supposed
>>>to contain the answer to your question.[/color]
>>
>>Umm... I know! I think. Can I answer for the OP?[/color]
>
>
> Me too, I think because then someone would ask, "Why not DeviceNET" and[/color]
I was going to ask "Why not SNA?"
[color=blue]
> then we'd add that to C and next thing you know, C would only be able to
> run on hosted implementations .[/color]
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.
To take it a step further, how about abstracting network access into the
implementation of the stdio library? This way, the language wouldn't
have to change to provide networking features. To show what I mean, take
the following example program:
#include <stdio.h>
#include <stdlib.h>
int main(void)
{
FILE *data;
if ((data = fopen("data","w ")) != NULL)
fprintf(data,"H ello, World\n");
fclose(data);
return EXIT_SUCCESS;
}
The above program /obviously/ writes to a file called "data". Now, look
at this minor modification:
#include <stdio.h>
#include <stdlib.h>
int main(void)
{
FILE *data;
if ((data = fopen("tcp:127. 0.0.1:9","w")) != NULL)
fprintf(data,"H ello, World\n");
fclose(data);
return EXIT_SUCCESS;
}
Does the above program write to the file called "tcp:127.0.0.1: 9", or
does it establish a TCP connection with the local discard service and
send it some data? Does it matter, wrt ISO C?
- --
Lew Pitcher, IT Consultant, Enterprise Application Architecture
Enterprise Technology Solutions, TD Bank Financial Group
(Opinions expressed here are my own, not my employer's)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
iD8DBQFA9DjmagV FX4UWr64RAo83AJ 48OYnhgsXXDkllL 1ssype0VxMBVwCg qGyU
oZScRtcwsOC0yBB 5H/kp8aE=
=5DqQ
-----END PGP SIGNATURE-----
Comment
-
[OT] Re: Why not networking support?
On Tue, 13 Jul 2004, Lew Pitcher wrote:[color=blue]
>
> 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.[/color]
Probably because it wouldn't be useful (which AFAICT was Dan's original
point). 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.
Why TCP/IP when what I *really* need is DS/IP (DeathStation Internet
Protocol)? :)
[color=blue]
> To take it a step further, how about abstracting network access into the
> implementation of the stdio library? This way, the language wouldn't
> have to change to provide networking features. To show what I mean, take
> the following example program:[/color]
<snip>[color=blue]
> if ((data = fopen("tcp:127. 0.0.1:9","w")) != NULL)
>
> Does the above program write to the file called "tcp:127.0.0.1: 9", or
> does it establish a TCP connection with the local discard service and
> send it some data? Does it matter, wrt ISO C?[/color]
Doesn't matter at all. The networking solution is definitely a
perfectly reasonable behavior for a Windows compiler, since Windows
these days blurs the lines between the filesystem and the network
to the point of non-existence (merging Internet Explorer and File
Manager, e.g.). In a compiler explicitly targeted to Windows, I would
definitely expect that fopen("http://www.google.com/", "r") would
behave as if it were reading from a "normal" file full of HTML.
I don't know how much Linux or other OSen blur these lines, though;
I would expect the answer to be "less."
-Arthur
Comment
-
Re: Why not networking support?
Lew Pitcher wrote:[color=blue]
> [...]
> To take it a step further, how about abstracting network access into the
> implementation of the stdio library? This way, the language wouldn't
> have to change to provide networking features. To show what I mean, take
> the following example program:
>
> #include <stdio.h>
> #include <stdlib.h>
>
> int main(void)
> {
> FILE *data;
>
> if ((data = fopen("data","w ")) != NULL)
> fprintf(data,"H ello, World\n");
> fclose(data);
>
> return EXIT_SUCCESS;
> }
>
> The above program /obviously/ writes to a file called "data". Now, look
> at this minor modification:
>
> #include <stdio.h>
> #include <stdlib.h>
>
> int main(void)
> {
> FILE *data;
>
> if ((data = fopen("tcp:127. 0.0.1:9","w")) != NULL)
> fprintf(data,"H ello, World\n");
> fclose(data);
>
> return EXIT_SUCCESS;
> }
>
> Does the above program write to the file called "tcp:127.0.0.1: 9", or
> does it establish a TCP connection with the local discard service and
> send it some data? Does it matter, wrt ISO C?[/color]
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.)
For a concrete example of how different implementations
give different interpretations to identical file name strings,
try this program on several implementations and observe what
happens:
#include <stdio.h>
static void doit(const char *name, const char *text) {
FILE *stream = fopen(name, "w");
if (stream == NULL)
fprintf (stderr, "Can't open %s\n", name);
else {
fprintf (stream, "%s: %s\n", name, text);
fclose (stream);
}
}
int main(void) {
doit ("pro.txt", "Reasons to support euthanasia");
doit ("con.txt", "Reasons to oppose euthanasia");
return 0;
}
Another way to sneak new capabilities into the existing
Standard library interface would be to extend the "mode" string,
with implementation-defined significance for extra characters:
stream = fopen("127.0.0. 1:9", "wbTCP");
.... where the Standard defines the "wb" piece and the "TCP"
is a hypothetical implementation-specific add-on -- "undefined"
by the C Standard, but "definable" by cooperating extensions.
--
Eric.Sosman@sun .com
Comment
-
Re: Why not networking support?
H.A. Sujith wrote:
[color=blue]
> Why doesn't the standard library provide (at least basic)
> networking facilities using TCP/IP?[/color]
Why should it?
What's wrong with the current standards?
Why must C compiler developers implement and distribute
a standard library for networking facilities?
Comment
-
Re: Why not networking support?
"Mark A. Odell" <odellmark@hotm ail.com> wrote in message
news:Xns9525596 72C64CopyrightM arkOdell@130.13 3.1.4...[color=blue]
> "H.A. Sujith" <sujith@localho st.localdomain> wrote in
> news:slrncf7icc .2sr.sujith@loc alhost.localdom ain:
>[color=green]
> > Why doesn't the standard library provide (at least basic)
> > networking facilities using TCP/IP ?[/color]
>
> What does that mean to an 8-bit microcontroller with 128 bytes of RAM and
> 8kB of ROM?[/color]
What's your point in asking this question?
--
Peter
Comment
Comment