C needs a URL*

[Felix Palmen]

Is this open source, by any chance, or not?

It is: <http://sekrit.de/stoneage/>

But, it's still at alpha stage and the event propagation scheme is not
yet ready for merging in the trunk (almost there, though).

Regards, Felix

 

[Ben Bacarisse]

The problem is not the loss of one filename but the loss of dozens
already and potentially hundreds or even thousands in the future as more
URL schemes are defined--which current software and users don't know
anything about.

If you want to hack this ability into fopen(), it would have to be done
using a syntax that is guaranteed to be illegal today, and AFAIK there
can't be any such guarantee because the contents of the filename string
are implementation-defined.

Looking at this from a purely theoretical point of view, the obvious
choice would be a new mode modifier. If, say, the mode string starts
with ':' then the file name can be interpreted a new way without
altering any code that is not already undefined. Of course, there may
be systems where this undefined behaviour has been defined but at least
C's conscience will be clear!

 

[Rui Maciel]

Define "relevant"

By "relevant" I meant that which is important and indispensable. So, in other words, I was
referring to any application that is widely adopted and whose importance is unquestionable.

I thought most MS products were done using
C++/CLI and C#?

Not the MS Office line of products, nor Internet Explorer, Outlook Express, Visual Studio, Exchange,
etc... They are all reported to be developed in C++. It is also reported that Microsoft develops
it's OSs in C++[1]

Then virtually all web browsers are written in C++, such as Firefox, Chrome, Opera, Safari and
Konqueror. Epiphany is written in C. I don't know any browser which is written in either Java, C#
or any other language.

It is also said that Adobe and Autodesk also develop their products with either C, C++ or a mix of
both. I don't know if it's possible to generalize this for Autodesk's products, as AutoCAD has a
hefty chunk of it written in a LISP dialect.

So, where exactly do you base your allegation that "C++ [..] is itself being replaced by C#,
C++/CLI, Java and other languages."?

And regarding C, the GNOME desktop environment, along with practically all of its native
applications, are written in C. You don't get more "desktop language" than that.

A lot of web stuff is done with Java?

Are you referring to java applets?

I thought Eclipse was Java?

Eclipse is indeed written in Java. Yet, I don't believe an IDE can be considered a mainstream
desktop application.


Rui Maciel

[1] http://www2.research.att.com/~bs/applications.html

 

[Chris H]

In message <0.bbf230b00cd0d87b5b56.20100908150559BST.87tym0mit4.fsf@bsb.

Looking at this from a purely theoretical point of view, the obvious
choice would be a new mode modifier. If, say, the mode string starts
with ':' then the file name can be interpreted a new way without
altering any code that is not already undefined. Of course, there may
be systems where this undefined behaviour has been defined but at least
C's conscience will be clear!

This would of course make most C compilers even more non standard as I
can't see the vast majority bothering to implement it. It also assumes
far to many things.

It would be OK as an optional add on for those that want it. so how
about a separate wopen library call? Or a specific "w*" library for web
access.

 

[Chris H]

We live in an internet age. The distinction between files and
hyperdocuments on an external network hardly means anything any more.

Yet C is stuck with only FILE* access to local filesystems.

Because many systems don't have external access... indeed many do't even
have internal file systems

Want to read
a HTML document or an FTP file? You need an external library for that -
different and incompatible libraries on Windows or Unix or Apple.

What about the many other OS is common usage?

The next C standard urgently needs to include URL* as a first-class
object built right into the language, with uopen(), uclose(), uread(),
uwrite() functions to open and close internet documents right within the
C language.

Absolutely NOT

It's vital to the continuation of C's popularity as a DeskTop
programming language.

Not bothered about the desk top but the majority of C users would not
see it as vital. Many or most of their systems are not connected to the
Internet.

What is needed is a separate library.

 

[Chris H]

By "relevant" I meant that which is important and indispensable. So,
in other words, I was
referring to any application that is widely adopted and whose
importance is unquestionable.

Fair enough.

I thought most MS products were done using
C++/CLI and C#?

Not the MS Office line of products, nor Internet Explorer, Outlook
Express, Visual Studio, Exchange,
etc... They are all reported to be developed in C++. It is also
reported that Microsoft develops
it's OSs in C++[1]

Now I thought it was C++/CLI which is not really C++?

So, where exactly do you base your allegation that "C++ [..] is itself
being replaced by C#,
C++/CLI, Java and other languages."?

I was thinking of the MS stuff.

And regarding C, the GNOME desktop environment, along with practically
all of its native
applications, are written in C. You don't get more "desktop language"
than that.

What is GNOME?

Eclipse is indeed written in Java. Yet, I don't believe an IDE can be
considered a mainstream
desktop application.

Then very many programmers would disagree with you.

 

[Mark Bluemel]

We live in an internet age. The distinction between files and
hyperdocuments on an external network hardly means anything any more.

Yet C is stuck with only FILE* access to local filesystems. Want to read
a HTML document or an FTP file? You need an external library for that -
different and incompatible libraries on Windows or Unix or Apple.

The next C standard urgently needs to include URL* as a first-class
object built right into the language, with uopen(), uclose(), uread(),
uwrite() functions to open and close internet documents right within the
C language. It's vital to the continuation of C's popularity as a DeskTop
programming language.

Well...

Files aren't actually built into the language, though I believe that the
stdio functions are part of the C standard in a broader sense.

On that basis, it would be possible to make some sort of library system
for URLs part of a future standard, I suppose.

Whether it's vital, I rather doubt. Are you planning to provide parsing
for HTML? What about URLs pointing to flash etc?

 

[jacob navia]

Le 08/09/10 16:27, Chris H a écrit :

This would of course make most C compilers even more non standard as I
can't see the vast majority bothering to implement it. It also assumes
far to many things.

It would be OK as an optional add on for those that want it. so how
about a separate wopen library call? Or a specific "w*" library for web
access.

lcc-win implements this as:

int GetHttpUrl(char *url,char *localFileNme);

 

[Chris H]

Well...

Files aren't actually built into the language, though I believe that
the stdio functions are part of the C standard in a broader sense.

On that basis, it would be possible to make some sort of library system
for URLs part of a future standard, I suppose.

Whether it's vital, I rather doubt. Are you planning to provide parsing
for HTML? What about URLs pointing to flash etc?

The other problem is what exactly is this wopen going to talk to? How
is it going to see the Internet? Remember many (most) C compilers go to
bare metal. Many OS don't have a file system as standard let alone a
TCP/IP stack.....

 

[Ben Bacarisse]

Le 08/09/10 16:27, Chris H a écrit :

I don't really mind. As I said I was looking at it as a theoretical
problem about how to minimise disruption to existing fopen calls.

lcc-win implements this as:

int GetHttpUrl(char *url,char *localFileNme);

That looks like a very different interface to the one that have been
proposed. BTW, would it not be better to have const chat * parameters?

 

[Rui Maciel]

What is GNOME?

It's one of the main desktop environments, if not the main desktop environment, for Unix-like
operating systems, including linux-based software distributions. KDE is another desktop environment
which can be described as GNOME's rival. KDE is written in C++ and is built upon the most excellent
Qt framework.

You can check them out at:
http://www.gnome.org/
http://www.kde.org/


Rui Maciel

 

[Keith Thompson]

Because many systems don't have external access... indeed many do't even
have internal file systems

I don't think that's an issue as far as the proposed new feature
is concerned. System without internal file systems generally
have freestanding implementations (C99 4p6). Systems without file
systems but no internet access could simply have fopen() (or uopen()
fail when given a URL.

That's not to say I think the new feature is either necessary or
a good idea, but this isn't an obstacle to it.

 

[Chris H]

It's one of the main desktop environments, if not the main desktop
environment, for Unix-like

Oh... Unix like. You mean like Solaris? I have used that.

operating systems, including linux-based software distributions. KDE
is another desktop environment
which can be described as GNOME's rival. KDE is written in C++ and is
built upon the most excellent
Qt framework.

OK so they are not mainstream compared to Windows, OSX etc

 

[Chris H]

I don't think that's an issue as far as the proposed new feature
is concerned. System without internal file systems generally
have freestanding implementations (C99 4p6). Systems without file
systems but no internet access could simply have fopen() (or uopen()
fail when given a URL.

That's not to say I think the new feature is either necessary or
a good idea, but this isn't an obstacle to it.

Fair enough. However I can's see many implementing it.

We had the same problem with C99.... full of "good ideas" that few
people wanted. SO the industry is still at C95+ over a decade later.
C99 will be the standard that was never [fully] implemented. Not sure
where C1* is going either.

 

[Ben Pfaff]

Because there are platforms where "http://example.com/foo.txt" is a
perfectly valid path to a local file.

Well then, make the argument *always* be a URI. "file:" URLs can
refer to local files.

 

[Keith Thompson]

Well then, make the argument *always* be a URI. "file:" URLs can
refer to local files.

Perfect. That would break fewer than 99% of existing programs.

 

[Seebs]

You're thinking in set theory, not like a human. Loss of "http:" as a
directory name is a very small price to pay for transparent access to
the internet.

While you might feel that way, other people might not, and a proposed
loss of currently-working functionality in the standard would have to
be justified strongly enough to justify breaking existing code -- that's
a very high standard to reach.

Since you can't actually have transparent access to URLs anyway, it seems
sort of pointless. URLs require you to be a lot more aware of transient
failures and other special cases than files do.

-s

 

[Keith Thompson]

What's wrong with parsing a given URI and, whether it's a path

to a local file or a URI, you use the > according code to access
the resource?

Because there are platforms where "http://example.com/foo.txt" is a
perfectly valid path to a local file.

[root@localhost /tmp]$ mkdir http:
[root@localhost /tmp]$ mkdir http://example.com
[root@localhost /tmp]$ echo hello >http://example.com/foo.txt
[root@localhost /tmp]$ ls -l http://example.com/foo.txt
-rw-rw-r-- 1 root 6 Sep 8 12:52 http://example.com/foo.txt
[root@localhost /tmp]$ cat http://example.com/foo.txt
hello
[root@localhost /tmp]$ cat /tmp/http://example.com/foo.txt
hello
[root@localhost /tmp]$

And it's tempting to steal that small part of the namespace,
since there are very few real-world files with names that would
conflict. But it would create a number of special cases that many
general-purpose programs would have to work around. Inevitably,
some programs would not be updated to reflect the new file names,
which could open the door for malicious code to trick such programs
into opening URLs thinking that they're ordinary files.

Somebody mentioned that POSIX permits a leading // to be treated
specially. Non-POSIX systems probably have similar capabilities.

*If* this were to be done, it would make sense to have a separate
function, perhaps url_open(), that takes a URL and returns a FILE*.

For that matter, it's already possible (on POSIX systems with the
right software installed) to use popen() to invoke "curl" or "wget".

On the other other hand, many systems provide ways to mount external
information systems so that they appear to be within the file system.

 

[Rui Maciel]

Oh... Unix like. You mean like Solaris? I have used that.

Solaris, BSD, linux...

OK so they are not mainstream compared to Windows, OSX etc

It depends on what you consider mainstream to be. They certainly hold a smaller "market share", if
you can call it that.


Rui Maciel

 

[Rui Maciel]

Fair enough. However I can's see many implementing it.

You don't need to wait for a standards committee to implement such a library. You can simply
develop it on your own, release it under a free software license and then build a case to add your
library to the standards. There's nothing like a fully working prototype to evaluate a technology.


Rui Maciel