-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Dan said:
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.
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)
iD8DBQFA9WbXagVFX4UWr64RAmZ4AJ9E6oVzWE10ZalXj4gykIDnuYjqewCg3V/J
D+lsMufjH48ELaPN2Q4AsNU=
=ZPS7
-----END PGP SIGNATURE-----
