Re: C needs a URL*
- From: Kenneth Brody <kenbrody@xxxxxxxxxxx>
- Date: Thu, 09 Sep 2010 12:22:44 -0400
On 9/8/2010 2:41 PM, Rui Maciel wrote:
Kenneth Brody wrote:
Because there are platforms where "http://example.com/foo.txt" is a
perfectly valid path to a local file.
This is irrelevant. It's one thing for a string such as "http://example.com/foo.txt" to be a valid
path to a local file but an URI is an entirely different concept. For example, if we rely on URIs
to refer to resources then the following would be two entirely different resources:
with the former referring to an internet resource which is available at example.com/foo.txt through
the HTTP protocol while the latter would refer to a local file available at
Then perhaps a new function, perhaps called "uriopen()" would be more appropriate, rather than co-opting the existing fopen()?
In order to avoid ambiguity then it would be possible to default to interpret a given text string as
a path to a local file if no URI scheme name was provided.
We have already shown that "http://example.com/foo.txt" is a valid local filename on some systems. Which interpretation do you use, if you allow local filenames to exclude the "file:" prefix?
If a new uriopen() function were to be created, it could insist that the "file:" prefix be used.
Nevertheless, I don't believe that fudging stdio.h and it's palls is remotely desirable or
justifiable. If such a functionality is really that useful, which I don't see why or how, it should
simply be made available through a library.
I also don't think it belongs as part of the language spec. Perhaps a place like POSIX might be appropriate, however? Or perhaps a set of "standard", but distinct from the language itself, libraries?
- Prev by Date: Re: C Containers library
- Next by Date: Re: Free Download Lectures of C and C++ and many more
- Previous by thread: Re: C needs a URL*
- Next by thread: Re: C needs a URL*