[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

jacob navia

7/8/2011 11:00:00 AM

Mr wojtek_l@yahoo.ca (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...)

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/...)

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.

28 Answers

Ian Collins

7/8/2011 11:07:00 AM

0

On 07/ 8/11 10:59 PM, jacob navia wrote:
>
> In 1978 things are already well in place:
> (http://plan9.bell-labs.com/7thEdMan/...)
>
> 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

China Blue Veins

7/8/2011 11:41:00 AM

0

In article <97o6neF6tbU5@mid.individual.net>,
Ian Collins <ian-news@hotmail.com> 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.

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.)

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

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

--
I remember finding out about you, |A free Thai dyed shirt in every box.
Everyday my mind is all around you,| I'm whoever you want me to be.
Looking out from my lonely room | Annoying Usenet one post at a time.
Day after day. | At least I can stay in character.

Ian Collins

7/8/2011 11:47:00 AM

0

On 07/ 8/11 11:40 PM, China Blue Dolls wrote:
> In article<97o6neF6tbU5@mid.individual.net>,
> Ian Collins<ian-news@hotmail.com> 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

China Blue Veins

7/8/2011 12:16:00 PM

0

In article <97o927F6tmU1@mid.individual.net>,
Ian Collins <ian-news@hotmail.com> wrote:

> On 07/ 8/11 11:40 PM, China Blue Dolls wrote:
> > In article<97o6neF6tbU5@mid.individual.net>,
> > Ian Collins<ian-news@hotmail.com> 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.

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

> > 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.

--
I remember finding out about you, |A free Thai dyed shirt in every box.
Everyday my mind is all around you,| I'm whoever you want me to be.
Looking out from my lonely room | Annoying Usenet one post at a time.
Day after day. | At least I can stay in character.

James Kuyper

7/8/2011 12:19:00 PM

0

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

Todd Carnes

7/8/2011 1:10:00 PM

0

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

Seebs

7/8/2011 2:47:00 PM

0

On 2011-07-08, China Blue Dolls <chine.bleu@yahoo.com> 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 / usenet-nospam@seebs.net
http://www.seeb... <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/...(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

Seebs

7/8/2011 2:47:00 PM

0

On 2011-07-08, China Blue Dolls <chine.bleu@yahoo.com> wrote:
> In article <97o927F6tmU1@mid.individual.net>,
> Ian Collins <ian-news@hotmail.com> 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 / usenet-nospam@seebs.net
http://www.seeb... <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/...(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

China Blue Veins

7/8/2011 3:18:00 PM

0

In article <slrnj1e59s.21o0.usenet-nospam@guild.seebs.net>,
Seebs <usenet-nospam@seebs.net> wrote:

> On 2011-07-08, China Blue Dolls <chine.bleu@yahoo.com> wrote:
> > In article <97o927F6tmU1@mid.individual.net>,
> > Ian Collins <ian-news@hotmail.com> 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.)

I'm busy with imaging processing at the moment. I was thinking of going back to
my open and have it memory map files on block devices without specifying the
alignment or starting address. And then replace the read and write methods of a
channel object to copy the memory mapped pages. Then the OS would understand my
intentions exactly. Especially if I hint on serial access.

> The cycle of growth is this:
>
> 1. We understand that sometimes fopen() may not behave absolutely perfectly.
> 2. We try unbuffered I/O.

Unix I/O is peculiar to other systems of its era in that it required kernel
buffers and a kernel call to transfer between those buffers and user space. CIO
on NOS required the buffers allocated in user land. Other systems imposed a
record organisation on files. Whether the buffers were in the kernel or user
space could get fuzzy, especially on systems without protected system space.

> 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.

On Unix I use read/write or equivalents for sockets. Since sockets aren't block
devices, page alignment is not so important. What is important is ensuring
writes are flushed to the kernel before waiting on reads, and coping with
incomplete writes and reads due to network latency. I do use a library for this,
but never stdio.

> 6. We realize that this is what everyone was telling us about fopen().

I didn't use fopen with X keyboard and mouse either.

--
I remember finding out about you, |A free Thai dyed shirt in every box.
Everyday my mind is all around you,| I'm whoever you want me to be.
Looking out from my lonely room | Annoying Usenet one post at a time.
Day after day. | At least I can stay in character.

China Blue Veins

7/8/2011 3:30:00 PM

0

In article <slrnj1e553.21o0.usenet-nospam@guild.seebs.net>,
Seebs <usenet-nospam@seebs.net> wrote:

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

That would explain why so many people have replaced it.

> 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

And how often do people use a remote connection any more? An xterm is not a
remote connection. Most people now use desktop, laptops, and workstations. They
are rarely using telnet, ftp, etc directly.

> 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.

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

--
I remember finding out about you, |A free Thai dyed shirt in every box.
Everyday my mind is all around you,| I'm whoever you want me to be.
Looking out from my lonely room | Annoying Usenet one post at a time.
Day after day. | At least I can stay in character.