Why doesn't the standard library provide (at least basic)
networking facilities using TCP/IP ?
46  2021 
"H.A. Sujith" <su****@localhost.localdomain> wrote in
news:slrncf7icc.2sr.su****@localhost.localdomain: 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? 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 ->
--
On Tue, 13 Jul 2004 12:47:19 +0000, Mark A. Odell wrote: "H.A. Sujith" <su****@localhost.localdomain> wrote in
news:slrncf7icc.2sr.su****@localhost.localdomain:
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? 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.
Humm, file access wouldn't make much sense on such systems either..
Anyway original poster should rather turn to the posix specifications.
"H.A. Sujith" <su****@localhost.localdomain> wrote: Why doesn't the standard library provide (at least basic)
networking facilities using TCP/IP ?
Because not nearly all networks are TCP/IP, and when C was first
standardised, even fewer were.
Richard
In <sl*******************@localhost.localdomain> "H.A. Sujith" <su****@localhost.localdomain> writes: Why doesn't the standard library provide (at least basic)
networking 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.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Dan Pop <Da*****@cern.ch> scribbled the following: In <sl*******************@localhost.localdomain> "H.A. Sujith" <su****@localhost.localdomain> writes:Why doesn't the standard library provide (at least basic)
networking 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?
--
/-- Joona Palaste (pa*****@cc.helsinki.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
Joona I Palaste <pa*****@cc.helsinki.fi> wrote in
news:cd**********@oravannahka.helsinki.fi: Why doesn't the standard library provide (at least basic)
networking 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.
--
- Mark ->
--
Mark A. Odell <od*******@hotmail.com> scribbled the following: Joona I Palaste <pa*****@cc.helsinki.fi> wrote in
news:cd**********@oravannahka.helsinki.fi:Why doesn't the standard library provide (at least basic)
networking 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.
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 (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"To doo bee doo bee doo."
- Frank Sinatra
Joona I Palaste <pa*****@cc.helsinki.fi> wrote in
news:cd**********@oravannahka.helsinki.fi: >Why doesn't the standard library provide (at least basic)
>networking 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.
You are right, but that's not what I was thinking about. Maybe I read
too much into Dan's emphasis on _TCP/IP_?
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 ->
--
Mark A. Odell <od*******@hotmail.com> scribbled the following: Joona I Palaste <pa*****@cc.helsinki.fi> wrote in
news:cd**********@oravannahka.helsinki.fi:>>Why doesn't the standard library provide (at least basic)
>>networking 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.
You are right, but that's not what I was thinking about. Maybe I read
too much into Dan's emphasis on _TCP/IP_?
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.
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 (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"It sure is cool having money and chicks."
- Beavis and Butt-head
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Mark A. Odell wrote: Joona I Palaste <pa*****@cc.helsinki.fi> wrote in
news:cd**********@oravannahka.helsinki.fi:
Why doesn't the standard library provide (at least basic)
networking 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
I was going to ask "Why not SNA?"
then we'd add that to C and next thing you know, C would only be able to
run on hosted implementations.
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,"Hello, 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,"Hello, 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)
iD8DBQFA9DjmagVFX4UWr64RAo83AJ48OYnhgsXXDkllL1ssyp e0VxMBVwCgqGyU
oZScRtcwsOC0yBB5H/kp8aE=
=5DqQ
-----END PGP SIGNATURE-----
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). 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)? :)
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:
<snip> 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?
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
Lew Pitcher wrote: [...]
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,"Hello, 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,"Hello, 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?
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.
-- Er*********@sun.com
H.A. Sujith wrote: Why doesn't the standard library provide (at least basic)
networking facilities using TCP/IP?
Why should it?
What's wrong with the current standards?
Why must C compiler developers implement and distribute
a standard library for networking facilities?
"Mark A. Odell" <od*******@hotmail.com> wrote in message
news:Xn*******************************@130.133.1.4 ... "H.A. Sujith" <su****@localhost.localdomain> wrote in
news:slrncf7icc.2sr.su****@localhost.localdomain:
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?
What's your point in asking this question?
--
Peter
Lew Pitcher <Le*********@td.com> wrote: Mark A. Odell wrote: then we'd add that to C and next thing you know, C would only be able to
run on hosted implementations.
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.
Because networking is even less standardised than file systems. With a
file system at least you know that
- you have files, with names;
- files can be read, and written to;
- files may need to be opened, possibly in varying modes, and closed,
and where these are unnecessary, they're trivial no-ops;
- file operations may fail, but these failures can be detected.
With networks, things are not that simple. Some kinds of networks need
you to authenticate yourself, using name and password, before you can do
anything else. Some kinds don't allow you to authenticate, but may use
your network address to decide whether you're allowed to talk. Some
network services work directly; some use repeated question-and-response;
some set up a continuous connection. And whose abstraction model would
we use? OSI?
Richard
In article <cd**********@nntp1.jpl.nasa.gov>, E. Robert Tisdale wrote: H.A. Sujith wrote:
Why doesn't the standard library provide (at least basic)
networking facilities using TCP/IP?
Why should it?
What's wrong with the current standards?
Why must C compiler developers implement and distribute
a standard library for networking facilities?
The stdio library tries to provide a platform independent I/O library.
Twenty years ago networking may not have been as important or
as standardized as today. But TCP/IP has become the accepted standard and
networking has become a very important part in computing -- it has
become a part of what we call I/O.
The concept of sockets fits nicely with C's system of streams. It is sad
that we cant use the nice funtions of the stdio library for networking.
(Of course, we can manually do stuff like changing file descriptors but
things like that are prone to errors.) A consistent nertworking interface
would not only make applications more portable, it would also make more
applications portable.
Although most use of networking is done using high-level protocols
a standard network interface would still be useful. For example it would
make easier the development of platform independent libraries for high-level
protocols like HTTP.
--
mail to: randomzoo <at> spymac <dot> com
On 14 Jul 2004 07:49:22 -0700,
H.A. Sujith <su****@localhost.localdomain> wrote
in Msg. <slrncfa831.16p.su****@localhost.localdomain> Although most use of networking is done using high-level protocols
a standard network interface would still be useful. For example it would
make easier the development of platform independent libraries for high-level
protocols like HTTP.
Ever heard of POSIX?
--Daniel
--
"With me is nothing wrong! And with you?" (from r.a.m.p)
"Peter Nilsson" <ai***@acay.com.au> wrote in
news:40******@news.rivernet.com.au: > 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?
What's your point in asking this question?
That a TCP/IP stack would be difficult to fit in addition to what the
current ISO C compiler supports. Basically, C can be used, as it stands,
on many smaller devices - adding TCP/IP would make C more of a "big
system" language. Unnecessarily I might add.
--
- Mark ->
--
"H.A. Sujith" <su****@localhost.localdomain> wrote: In article <cd**********@nntp1.jpl.nasa.gov>, E. Robert Tisdale wrote: H.A. Sujith wrote:
Why doesn't the standard library provide (at least basic)
networking facilities using TCP/IP?
Why should it?
The stdio library tries to provide a platform independent I/O library.
Twenty years ago networking may not have been as important or
as standardized as today. But TCP/IP has become the accepted standard
No, it has not. It has become _an_ accepted standard. Not _the_. IPX is
not yet dead, for example.
Richard
On Wed, 14 Jul 2004, Mark A. Odell wrote:
MAO>"Peter Nilsson" <ai***@acay.com.au> wrote in
MAO>news:40******@news.rivernet.com.au:
MAO>
MAO>>> > Why doesn't the standard library provide (at least basic)
MAO>>> > networking facilities using TCP/IP ?
MAO>>>
MAO>>> What does that mean to an 8-bit microcontroller with 128 bytes of RAM
MAO>>> and 8kB of ROM?
MAO>>
MAO>> What's your point in asking this question?
MAO>
MAO>That a TCP/IP stack would be difficult to fit in addition to what the
MAO>current ISO C compiler supports. Basically, C can be used, as it stands,
MAO>on many smaller devices - adding TCP/IP would make C more of a "big
MAO>system" language. Unnecessarily I might add.
While I don't think that adding TCP/IP support to C makes sense (what
about UDP, TLI vs. sockets, ... and why not just use Posix) your argument
doesn't seem to work. I don't think that really small devices would
support the full hosted environment, do they? An 8-bit microcontroller
with the above characteristics wouldn't support all the standard library.
Also it seems that C is growing more optional parts or are the
standardisation people going to force decimal floating point and address
spaces on every implementation?
harti
In <Xn*******************************@130.133.1.4> "Mark A. Odell" <od*******@hotmail.com> writes: "H.A. Sujith" <su****@localhost.localdomain> wrote in
news:slrncf7icc.2sr.su****@localhost.localdomai n:
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? 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.
Bogus argument: does your implementation for the 8-bit microcontroller
with 128 bytes of RAM and 8kB of ROM come with a full implementation
of the standard C library? If the answer is no, would it matter if the
standard C library also included TCP/IP support?
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
In <pa****************************@Utel.no> =?iso-8859-1?q?Nils_O=2E_Sel=E5sdal?= <NO*@Utel.no> writes: On Tue, 13 Jul 2004 12:47:19 +0000, Mark A. Odell wrote:
"H.A. Sujith" <su****@localhost.localdomain> wrote in
news:slrncf7icc.2sr.su****@localhost.localdomain:
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? 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.
Humm, file access wouldn't make much sense on such systems either..
Anyway original poster should rather turn to the posix specifications.
The original POSIX standard knows about TCP/IP as much as the C standard.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
In <Xn********************************@130.133.1.4> "Mark A. Odell" <od*******@hotmail.com> writes: Joona I Palaste <pa*****@cc.helsinki.fi> wrote in
news:cd**********@oravannahka.helsinki.fi:
Why doesn't the standard library provide (at least basic)
networking 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?
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Dan Pop <Da*****@cern.ch> scribbled the following: In <Xn********************************@130.133.1.4> "Mark A. Odell" <od*******@hotmail.com> writes:Joona I Palaste <pa*****@cc.helsinki.fi> wrote in
news:cd**********@oravannahka.helsinki.fi:>Why doesn't the standard library provide (at least basic)
>networking 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?
--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"It sure is cool having money and chicks."
- Beavis and Butt-head
"Mark A. Odell" <od*******@hotmail.com> writes: "H.A. Sujith" <su****@localhost.localdomain> wrote in
news:slrncf7icc.2sr.su****@localhost.localdomain:
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.
--
int main(void){char p[]="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuv wxyz.\
\n",*q="kl BIcNBFr.NKEzjwCIxNJC";int i=sizeof p/2;char *strchr();int putchar(\
);while(*q){i+=strchr(p,*q++)-p;if(i>=(int)sizeof p)i-=sizeof p-1;putchar(p[i]\
);}return 0;}
In <40**************@sun.com> Eric Sosman <Er*********@sun.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.
So, you can rely on fopen() for opening a file, if the user provides a
proper file name, but you can't rely on fopen() for opening a network
connection, no matter what the user does.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
In <MN********************@news20.bellglobal.com> Lew Pitcher <Le*********@td.com> writes: 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 most likely answer would be: lack of existing practice. So, if some
popular implementor does it, there are chances for it to become a
standard feature. Until then, we're in the good old "the egg and
the hen" deadlock ;-)
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Dan Pop wrote: In <40**************@sun.com> Eric Sosman <Er*********@sun.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 implementationfrom 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\\system32\\etc\\services" 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.
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.
So, you can rely on fopen() for opening a file,
Ahh, but what is a "file"? AFAICT, C only has two requirements for a file:
1) that it can be manipulated by the f*() functions (fopen(), fread(),
etc.), and
2) the data retrieved from or written to it must be of an integral type,
or storable in an array of char.
I don't believe that the C standard dictates the storage media for a
file, nor it's organization wrt other files. I dont believe that the
standard even requires that files follow a particular naming convention.
And I don't see how network data fails to satisfy the two requirements,
when manipulated by the f*() functions.
if the user provides a
proper file name, but you can't rely on fopen() for opening a network
connection, no matter what the user does.
But, what dictates a "proper file name"? Is "DD:SYSIN" guaranteed to
exist /as the name of a file/? (I can assure you that, on the platform
from which that example comes, "DD:SYSIN" does /not/ exist as the name
of a file.) Or, how about "LPT:"? Is there always a /file/ associated
with that name? (Again, no, when you refer to the specific platform).
The point is that the C standard does not dictate the meaning of the
name given to the f*() functions, just like it doesn't dictate the
meaning of the string given to system(). All the standard /does/ require
is that the named resource /behave/ as a file. If "tcp:127.0.0.1:9"
behaves as a file, then it doesn't matter if the /implementation/
implements it as a file or as a network connection.
So, with this approach, networking can be fit within the confines of the
C standard /just like file I/O/, with the same implementation-dependant
caveats as file I/O has.
Dan
Lest you get the wrong idea, I proposed the "tcp:127.0.0.1:9" behaviour
as an illustration of why an explicit network api is not needed in C.
I doubt that ISO C will include an explicit networking api, /because/
generic networking can be handled with the current file I/O api with the
same sort of platform and implementation-specific work "under the
covers" that ISO C standard file I/O currently requires.
- --
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)
iD8DBQFA9WbXagVFX4UWr64RAmZ4AJ9E6oVzWE10ZalXj4gykI DnuYjqewCg3V/J
D+lsMufjH48ELaPN2Q4AsNU=
=ZPS7
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Dan Pop wrote: In <MN********************@news20.bellglobal.com> Lew Pitcher
<Le*********@td.com> writes:
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 most likely answer would be: lack of existing practice. So, if some
popular implementor does it, there are chances for it to become a
standard feature. Until then, we're in the good old "the egg and
the hen" deadlock ;-)
That's an answer I can live with :-)
Until some C implementation actually /implements/ this behaviour, we
won't ever /see/ this behaviour.
Perhaps we can convince PJP that Dinkumware /needs/ to implement
networking within their stdio library <vbg>
- --
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)
iD8DBQFA9WdeagVFX4UWr64RAlwbAJ0eTfpv6pxmWKxQHTLDwe NQTdbMmACgv3Lt
UYMI3MdTiGE8Qmh3+2TwTCo=
=UOUz
-----END PGP SIGNATURE-----
In <Pi**********************************@unix42.andre w.cmu.edu> "Arthur J. O'Dwyer" <aj*@nospam.andrew.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
In <cd**********@oravannahka.helsinki.fi> Joona I Palaste <pa*****@cc.helsinki.fi> writes: Dan Pop <Da*****@cern.ch> scribbled the following: In <Xn********************************@130.133.1.4> "Mark A. Odell" <od*******@hotmail.com> writes:Joona I Palaste <pa*****@cc.helsinki.fi> wrote in
news:cd**********@oravannahka.helsinki.fi:
>>Why doesn't the standard library provide (at least basic)
>>networking 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
# 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.
SM Ryan <wy*****@tango-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_Keith) 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.
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>iD8DBQFA9WdeagVFX4UWr64RAlwbAJ0eTfpv6pxmWKxQHTL DweNQTdbMmACgv3Lt
LP>UYMI3MdTiGE8Qmh3+2TwTCo=
LP>=UOUz
LP>-----END PGP SIGNATURE-----
LP>
Ben Pfaff <bl*@cs.stanford.edu> wrote in news:87************@benpfaff.org: 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 ->
-- 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 ->
--
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*********@sun.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 implementationfrom 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\\system32\\etc\\services" 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
In <Xn********************************@130.133.1.4> "Mark A. Odell" <od*******@hotmail.com> writes: 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?
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
"Mark A. Odell" <od*******@hotmail.com> writes: Ben Pfaff <bl*@cs.stanford.edu> wrote in news:87************@benpfaff.org:
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 Da*****@cern.ch (Dan Pop) writes: In <Xn********************************@130.133.1.4> "Mark A. Odell"
<od*******@hotmail.com> writes:
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?
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 (The_Other_Keith) 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. Da*****@cern.ch (Dan Pop) writes:
[...] When someone starts splitting hairs, it's better to leave him play his
game alone.
Indeed.
--
Keith Thompson (The_Other_Keith) 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.
On 13 Jul 2004 07:26:38 -0700, in comp.lang.c , "H.A. Sujith"
<su****@localhost.localdomain> wrote: 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
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==---- http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
On Tue, 13 Jul 2004 15:32:56 -0400, in comp.lang.c , Lew Pitcher
<Le*********@td.com> 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?
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! :-)
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==---- http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Mark McIntyre <ma**********@spamcop.net> writes: On 13 Jul 2004 07:26:38 -0700, in comp.lang.c , "H.A. Sujith"
<su****@localhost.localdomain> wrote: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.
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.
--
Keith Thompson (The_Other_Keith) 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.
In <ln************@nuthaus.mib.org> Keith Thompson <ks***@mib.org> writes: Da*****@cern.ch (Dan Pop) writes:
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*?
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
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
In <ln************@nuthaus.mib.org> Keith Thompson <ks***@mib.org> writes: Mark McIntyre <ma**********@spamcop.net> writes: On 13 Jul 2004 07:26:38 -0700, in comp.lang.c , "H.A. Sujith"
<su****@localhost.localdomain> wrote: >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.
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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Fibre Optic |
last post by:
Hi,
I am looking for good book about network programming in C++. Probably it
will difficult to find out book which explain such complicated subject
for MS Windows & Linux but ... Could some one...
|
by: KevinGPO |
last post by:
Two quick queries:
1. I have programmed a little network performance monitor. It monitors
a set of remote hosts over a network. It gets the CPU statistics and
all gets collected at one of the...
|
by: Brian Keogh |
last post by:
Hi,
I'm a student learning TCP/IP networking at University. Although I
understand all about TCP/IP Networking in Java I am expected to understand
the basics of C with regard to these programs as...
|
by: isladogs |
last post by:
The next Access Europe meeting will be on Wednesday 4 Oct 2023 starting at 18:00 UK time (6PM UTC+1) and finishing at about 19:15 (7.15PM)
The start time is equivalent to 19:00 (7PM) in Central...
|
by: tracyyun |
last post by:
Hello everyone,
I have a question and would like some advice on network connectivity. I have one computer connected to my router via WiFi, but I have two other computers that I want to be able to...
|
by: giovanniandrean |
last post by:
The energy model is structured as follows and uses excel sheets to give input data:
1-Utility.py contains all the functions needed to calculate the variables and other minor things (mentions...
|
by: NeoPa |
last post by:
Hello everyone.
I find myself stuck trying to find the VBA way to get Access to create a PDF of the currently-selected (and open) object (Form or Report).
I know it can be done by selecting :...
|
by: NeoPa |
last post by:
Introduction
For this article I'll be using a very simple database which has Form (clsForm) & Report (clsReport) classes that simply handle making the calling Form invisible until the Form, or all...
|
by: Teri B |
last post by:
Hi, I have created a sub-form Roles. In my course form the user selects the roles assigned to the course.
0ne-to-many. One course many roles.
Then I created a report based on the Course form and...
|
by: isladogs |
last post by:
The next Access Europe meeting will be on Wednesday 1 Nov 2023 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM)
Please note that the UK and Europe revert to winter time on...
|
by: nia12 |
last post by:
Hi there,
I am very new to Access so apologies if any of this is obvious/not clear.
I am creating a data collection tool for health care employees to complete. It consists of a number of...
|
by: SueHopson |
last post by:
Hi All,
I'm trying to create a single code (run off a button that calls the Private Sub) for our parts list report that will allow the user to filter by either/both PartVendor and PartType. On...
| |
