Re: C needs a URL*



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:

http://example.com/foo.txt
file:///http://example.com/foo.txt


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
/http://example.com/foo.txt.

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?

--
Kenneth Brody
.