Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > fopen

Reply
Thread Tools

fopen

 
 
jacob navia
Guest
Posts: n/a
 
      07-08-2011
Mr http://www.velocityreviews.com/forums/(E-Mail Removed) (Wojtek Lerch) wrote:

> Do you find fopen() absurd and impossible to use too? Or are file or
> stream attributes (such as the POSIX permission bits, or O_EXCL) less
> important to you than some of the thread attributes that POSIX or
> Windows have?


That prompted me to study a bit the history of fopen(). Where does it
come from? When was the first version of fopen?

The oldest version of it that I found a reference to was in the first
Unix Manual: (http://cm.bell-labs.com/cm/cs/who/dmr/man31.pdf)

mov $filename , r0
jsr r5,fopen; iobuf

It is dated from Nov 3rd 1971. It says in the "Bugs" section:

For greater speed, the buffer should be 512 bytes long. Unfortunately,
this will cause several existing programs to stop working.

!!!

In 1978 things are already well in place:
(http://plan9.bell-labs.com/7thEdMan/index.html)

NAME
-fopen, freopen, fdopen - open a stream

SYNOPSIS
#include <stdio.h>
FILE *fopen(filename, type)
char *filename, *type;

DESCRIPTION
fopen opens the file named by filename and associates a stream with it.
fopen returns a pointer to be used to identify the stream in subsequent
operations.
Type is a character string having one of the following values:
"r" open for reading
"w" create for writing
"a" append: open for writing at end of file, or create for writing

----------------------------------------------------------------------

The interface of fopen has then at least 33 years. A whole professional
life.

When designing interfaces NOW, taking as an example fopen() one of the
oldest interfaces still in use is not really a good idea.

Considerations that then were crucial (small RAM footprint, efficiency,
etc) aren't of such an importance now, with machines that have 3 or 4
orders of magnitude more RAM and much more power.

 
Reply With Quote
 
 
 
 
Ian Collins
Guest
Posts: n/a
 
      07-08-2011
On 07/ 8/11 10:59 PM, jacob navia wrote:
>
> In 1978 things are already well in place:
> (http://plan9.bell-labs.com/7thEdMan/index.html)
>
> NAME
> -fopen, freopen, fdopen - open a stream
>
> SYNOPSIS
> #include<stdio.h>
> FILE *fopen(filename, type)
> char *filename, *type;
>
> DESCRIPTION
> fopen opens the file named by filename and associates a stream with it.
> fopen returns a pointer to be used to identify the stream in subsequent
> operations.
> Type is a character string having one of the following values:
> "r" open for reading
> "w" create for writing
> "a" append: open for writing at end of file, or create for writing
>
> ----------------------------------------------------------------------
>
> The interface of fopen has then at least 33 years. A whole professional
> life.


Does that mean I expire in a couple of years?

> When designing interfaces NOW, taking as an example fopen() one of the
> oldest interfaces still in use is not really a good idea.


Um, what else do you want when opening a fie?

> Considerations that then were crucial (small RAM footprint, efficiency,
> etc) aren't of such an importance now, with machines that have 3 or 4
> orders of magnitude more RAM and much more power.


A) none of those criteria apply to fopen().

B) make that 5 or 6 orders of magnitude!

--
Ian Collins
 
Reply With Quote
 
 
 
 
Ian Collins
Guest
Posts: n/a
 
      07-08-2011
On 07/ 8/11 11:40 PM, China Blue Dolls wrote:
> In article<(E-Mail Removed)>,
> Ian Collins<(E-Mail Removed)> wrote:
>
>>> When designing interfaces NOW, taking as an example fopen() one of the
>>> oldest interfaces still in use is not really a good idea.

>>
>> Um, what else do you want when opening a fie?

>
> A bufferred disc file copies disc sectors to virtual memory which can be paged
> to disc. Which fopen can act as a rather complicated disc to disc copier. Memory
> mapping files on pageable devices (as Multics did) gives you more control over
> paging and page alignment.


But that's just detail. Let the OS manage all the paging behind the
scenes.

> And the request/response nature of sockets isn't handled well with fopen buffers.


They (sockets) don't make sense at all with the fxxx() family.

--
Ian Collins
 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      07-08-2011
On 07/08/2011 07:06 AM, Ian Collins wrote:
> On 07/ 8/11 10:59 PM, jacob navia wrote:

....
>> When designing interfaces NOW, taking as an example fopen() one of the
>> oldest interfaces still in use is not really a good idea.

>
> Um, what else do you want when opening a fie?


Take a look at the options available when using the unix system function
open() and fcntl(). C streams only support a small fraction of those
options. Of course, the fraction that they do support includes all of
the most popular ones; I've seldom had any need to use the ones they
don't support.
--
James Kuyper
 
Reply With Quote
 
Todd Carnes
Guest
Posts: n/a
 
      07-08-2011
On Fri, 08 Jul 2011 12:59:50 +0200, jacob navia wrote:

> Considerations that then were crucial (small RAM footprint, efficiency,
> etc) aren't of such an importance now, with machines that have 3 or 4
> orders of magnitude more RAM and much more power.


Small RAM footprint, efficiency, etc... *ARE* still important today and
always will be. Not trying to attain such things, when one can, is just
plain laziness on the programmer's part.

Not every C program that is written is destined to be run on the latest
and greatest gamer's rig.

Todd
 
Reply With Quote
 
Seebs
Guest
Posts: n/a
 
      07-08-2011
On 2011-07-08, China Blue Dolls <(E-Mail Removed)> wrote:
> A bufferred disc file copies disc sectors to virtual memory which can be paged
> to disc. Which fopen can act as a rather complicated disc to disc copier. Memory
> mapping files on pageable devices (as Multics did) gives you more control over
> paging and page alignment.


Er.

In general, C implementations will do a reasonable job of implementing fopen()
sensibly.

> Also the bufferring of tty style devices only really made sense for the decade
> or two when telnet and modem muxes were the dominant connection between
> terminals and computers. X-Windows and the Xerox windows that beget Macs and
> Windows once again have the CPU reacting to each single character as it is
> typed. (Terminal.app and xterm actually use per-character events to simulate a
> telnet-like connection.)


This doesn't make any sense.

The major advantage of tty buffering is efficiency over connections where
latency is relatively high. Such as, say, any remote connection whatsoever.
If you've got access to machines which support both character and line
buffering, and aren't physically adjacent, try it out sometime; line buffering
with local editing is a huge win.

> And the request/response nature of sockets isn't handled well with fopen buffers.


Which is why no one uses it that way.

> fopen does make sense for nonpageable devices like.....ummm....does anyone still
> use tape drives? Parallel port printers?


fopen makes sense for plain files. Arguing that it's possible that the buffer
will get paged is... well, frankly, totally irrelevant. The parts of the
system that do buffering are usually aware of those tradeoffs.

-s
--
Copyright 2011, all wrongs reversed. Peter Seebach / (E-Mail Removed)
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
 
Reply With Quote
 
Seebs
Guest
Posts: n/a
 
      07-08-2011
On 2011-07-08, China Blue Dolls <(E-Mail Removed)> wrote:
> In article <(E-Mail Removed)>,
> Ian Collins <(E-Mail Removed)> wrote:
>> But that's just detail. Let the OS manage all the paging behind the
>> scenes.


> That requires fopen to be unbufferred or buffers to be page aligned.


I have this feeling that if only I were drunk, I could comprehend this.

The OS typically provides the C library, which is written with direct
knowledge of how the OS does paging.

Tell you what. On your choice of modern operating systems, give it a
try. Use an unbuffered read mechanism, then try a buffered one, and see
how they perform. (Note that fopen() allows you to turn off buffering.)

The cycle of growth is this:

1. We understand that sometimes fopen() may not behave absolutely perfectly.
2. We try unbuffered I/O.
3. We realize that unbuffered I/O is painfully slow and inefficient.
4. We write a little wrapper around our unbuffered I/O to provide buffering.
5. We realize that the wrapper is so useful it should be in a library.
6. We realize that this is what everyone was telling us about fopen().

-s
--
Copyright 2011, all wrongs reversed. Peter Seebach / (E-Mail Removed)
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
 
Reply With Quote
 
Seebs
Guest
Posts: n/a
 
      07-08-2011
On 2011-07-08, China Blue Dolls <(E-Mail Removed)> wrote:
> In article <(E-Mail Removed)>,
> Seebs <(E-Mail Removed)> wrote:
>> In general, C implementations will do a reasonable job of implementing
>> fopen()
>> sensibly.


> That would explain why so many people have replaced it.


How many are those? I'm not sure I've ever seen a replacement of
fopen() outside of newbie code.

> And how often do people use a remote connection any more?


Pretty much constantly. Do you know the word "server"?

Do you seriously think that server farms have keyboards and mice on
everything?

> I hate to break to you, but stdio is increasingly the interface
> of last resort.


And your authority for this statement is?

Everything I've seen from you suggests that you are one of those people
who hasn't yet gotten a sense of just how huge the world of computing is,
and you tend to overgeneralize from a very limited personal experience.

I don't know that much about the bulk of the computing world, but I'm
at least *aware* that my experience is in a few smallish subsets. All I
mostly work with is desktops, servers, embedded systems, and the like.

-s
--
Copyright 2011, all wrongs reversed. Peter Seebach / (E-Mail Removed)
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
 
Reply With Quote
 
Seebs
Guest
Posts: n/a
 
      07-08-2011
On 2011-07-08, China Blue Dolls <(E-Mail Removed)> wrote:
> Here's one: http://tcl.sourceforge.net/
> Possibly another: http://www.python.org/download/source/


Language implementors are a sort of special case.

>> Pretty much constantly. Do you know the word "server"?


> Again your experience betrays you.


Yeah.

> I have run HTTP through telnet for debugging,
> but usually I use a browser. Safari/FireFox/Chrome/Opera use the sockets, not
> me. MT-Newswatcher uses sockets, not me. Mail uses sockets, not me. I don't even
> do FTP by hand anymore.


Yeah, uhm.

Not what I was talking about.

> Server farms are usually unmonitorred. Some servers have a keyboard and monitor
> mounted in the rack, some are attached from a trolley, some are remotely
> administerred. For the most part however they churn away without any people
> connecting to a telnet, ssh, or serial port.


And yet, people who use stuff like build farms end up logging into machines
all the time.

I think the difference is, you're really happy to view the latest and newest
and best things as the entire world, and I'm used to having to care about
stuff that isn't like that.

There's a reason that screen and tmux exist and are actively maintained, and
it's not that no one uses command line tools remotely anymore.

-s
--
Copyright 2011, all wrongs reversed. Peter Seebach / (E-Mail Removed)
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
 
Reply With Quote
 
BGB
Guest
Posts: n/a
 
      07-08-2011
On 7/8/2011 6:10 AM, Todd Carnes wrote:
> On Fri, 08 Jul 2011 12:59:50 +0200, jacob navia wrote:
>
>> Considerations that then were crucial (small RAM footprint, efficiency,
>> etc) aren't of such an importance now, with machines that have 3 or 4
>> orders of magnitude more RAM and much more power.

>
> Small RAM footprint, efficiency, etc... *ARE* still important today and
> always will be. Not trying to attain such things, when one can, is just
> plain laziness on the programmer's part.
>
> Not every C program that is written is destined to be run on the latest
> and greatest gamer's rig.
>


yeah...

and, my projects, although relatively "lean" by modern PC standards,
will still have to have their memory footprint somewhat shaved down to
really be practical, say, on Android devices (me starting a new personal
project of trying to port some of my VM stuff, ... to work on Android).
I doubt it will really be all that terribly useful though, given both
the constrained resources and nature of the UI (it has given me some
ZUI-related thoughts though).

actually, I am initially porting it to Linux/ARM in an emulator (first
major goal: make it all work on ARM, as-is it is all a bit x86
specific...), rather than directly to Android, since it is a little
easier to develop and test on a target where I have things like, say,
the ability to look at console output, ...


anyways, in what ways is fopen()'s interface subject to performance or
memory concerns?...

well, in my case I have a VFS which does a lot more "stuff", but still
uses an interface similar to "fopen()"/... it has itself been in use in
my projects since the late 90s or so, originally intended to address
some uses which were not readily addressable with stdio's FS interface
(mostly in-program virtual files, ...).

some years back, its internals were rewritten, mostly to make it simpler
and less nasty, but dropping some functionality (mostly sockets and more
esoteric features), which I have not as of yet bothered to re-add.


or such...
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
fopen() with full path affecting subsequent fopen calls Michel Rouzic C Programming 4 04-28-2008 04:48 PM
What is up with fopen??? FOpen and local directories Nonee HTML 2 10-25-2005 09:18 PM
What can cause a fopen call to lock up? Mister Zimbu C++ 2 10-27-2004 04:02 PM
fopen / OPEN_MAX Kushal Agarwal C++ 2 09-17-2004 12:56 AM
iostreams equivalent to C's fopen "r+" Dave O'Hearn C++ 10 11-25-2003 02:03 AM



Advertisments