Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #7952 > unrolled thread

fopen

Back to article view | Back to comp.lang.c

Contents

  fopen jacob navia <jacob@spamsink.net> - 2011-07-08 12:59 +0200
    Re: fopen Ian Collins <ian-news@hotmail.com> - 2011-07-08 23:06 +1200
      Re: fopen China Blue Dolls <chine.bleu@yahoo.com> - 2011-07-08 04:40 -0700
        Re: fopen Ian Collins <ian-news@hotmail.com> - 2011-07-08 23:46 +1200
          Re: fopen China Blue Dolls <chine.bleu@yahoo.com> - 2011-07-08 05:15 -0700
            Re: fopen Seebs <usenet-nospam@seebs.net> - 2011-07-08 14:47 +0000
              Re: fopen China Blue Dolls <chine.bleu@yahoo.com> - 2011-07-08 08:18 -0700
              Re: fopen Angel <angel+news@spamcop.net> - 2011-07-08 19:37 +0000
                Re: fopen China Blue Dolls <chine.bleu@yahoo.com> - 2011-07-08 13:02 -0700
        Re: fopen Seebs <usenet-nospam@seebs.net> - 2011-07-08 14:47 +0000
          Re: fopen China Blue Dolls <chine.bleu@yahoo.com> - 2011-07-08 08:29 -0700
            Re: fopen Seebs <usenet-nospam@seebs.net> - 2011-07-08 15:55 +0000
              Re: fopen China Blue Dolls <chine.bleu@yahoo.com> - 2011-07-08 09:19 -0700
                Re: fopen Seebs <usenet-nospam@seebs.net> - 2011-07-08 17:21 +0000
                Re: fopen Keith Thompson <kst-u@mib.org> - 2011-07-08 13:39 -0700
                  Re: fopen China Blue Dolls <chine.bleu@yahoo.com> - 2011-07-08 17:17 -0700
                    Re: fopen Keith Thompson <kst-u@mib.org> - 2011-07-08 17:39 -0700
                  Re: fopen Seebs <usenet-nospam@seebs.net> - 2011-07-09 06:04 +0000
                    Re: fopen China Blue Dolls <chine.bleu@yahoo.com> - 2011-07-09 01:39 -0700
            Re: fopen Ian Collins <ian-news@hotmail.com> - 2011-07-09 08:23 +1200
            Re: fopen Dr Nick <3-nospam@temporary-address.org.uk> - 2011-07-09 07:47 +0100
            Re: fopen Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-07-09 06:55 -0700
              Re: fopen Nobody <nobody@nowhere.com> - 2011-07-10 05:26 +0100
                Re: fopen Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-07-10 02:33 -0700
      Re: fopen James Kuyper <jameskuyper@verizon.net> - 2011-07-08 08:18 -0400
        Re: fopen Ian Collins <ian-news@hotmail.com> - 2011-07-09 08:18 +1200
        Re: fopen Dr Nick <3-nospam@temporary-address.org.uk> - 2011-07-09 07:52 +0100
    Re: fopen Todd Carnes <toddcarnes@gmail.com> - 2011-07-08 13:10 +0000
      Re: fopen BGB <cr88192@hotmail.com> - 2011-07-08 12:25 -0700

Page 1 of 2  [1] 2  Next page →

#7952 — fopen

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

[toc] | [next] | [standalone]

#7953

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

[toc] | [prev] | [next] | [standalone]

#7954

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.

[toc] | [prev] | [next] | [standalone]

#7956

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

[toc] | [prev] | [next] | [standalone]

#7961

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.

[toc] | [prev] | [next] | [standalone]

#7972

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

[toc] | [prev] | [next] | [standalone]

#7979

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.

[toc] | [prev] | [next] | [standalone]

#7998

On 2011-07-08, 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.)

Well, why not, I'm bored. Very quick & dirty file copying program, using
stream I/O:


#include <stdio.h>

int main(int argc, char *argv[])
{
	if (argc < 3)
	{
		fprintf(stderr, "Usage: %s <src> <dst>\n", argv[0]);
		return 1;
	}

	FILE *src = fopen(argv[1], "r");
	FILE *dst = fopen(argv[2], "w");

	int data;
	while ((data = fgetc(src)) != EOF)
		fputc(data, dst);
	
	fclose(src);
	fclose(dst);
}

Test results of copying one file, size 46M, from a nfs share to a local
disk:

real    0m12.656s
user    0m1.227s
sys     0m0.087s


Same program, now done in unbuffered system calls. Note that the program
now is non-portable and more complex:


#include <stdio.h>

#include <unistd.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>

int main(int argc, char *argv[])
{
	if (argc < 3)
	{
		fprintf(stderr, "Usage: %s <src> <dst>\n", argv[0]);
		return 1;
	}

	int src = open(argv[1], O_RDONLY);
	int dst = open(argv[2], O_WRONLY | O_TRUNC);

	unsigned char data;
	while (read(src, &data, 1) == 1)
		write(dst, &data, 1);
	
	close(src);
	close(dst);
}

Test results, same file:

real    0m28.066s
user    0m6.861s
sys     0m21.180s


Mm... So using stream I/O gives me a 50% performance boost, makes my
program portable, and slightly easier to understand. I'd say it pays to
use stream I/O wherever possible. :-)


For those that want to know, the system used is an Intel Quad Core 6600
(2.6GHz), running 64-bit Gentoo Linux. The system where the nfs server
resides is a Sun Netra 200 (UltraSPARC IIe, 500 MHz RISC), running 64-bit
Gentoo Linux with 32-bit user land. Network is 100mbit CAT-5E.


-- 
"C provides a programmer with more than enough rope to hang himself.
C++ provides a firing squad, blindfold and last cigarette."
- seen in comp.lang.c

[toc] | [prev] | [next] | [standalone]

#8001

In article <slrnj1en40.486.angel+news@pearlgates.net>,
 Angel <angel+news@spamcop.net> wrote:

> On 2011-07-08, 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.)
> 
> Well, why not, I'm bored. Very quick & dirty file copying program, using
> stream I/O:
> 
> 
> #include <stdio.h>
> 
> int main(int argc, char *argv[])
> {
> 	if (argc < 3)
> 	{
> 		fprintf(stderr, "Usage: %s <src> <dst>\n", argv[0]);
> 		return 1;
> 	}
> 
> 	FILE *src = fopen(argv[1], "r");
> 	FILE *dst = fopen(argv[2], "w");
> 
> 	int data;
> 	while ((data = fgetc(src)) != EOF)
> 		fputc(data, dst);
> 	
> 	fclose(src);
> 	fclose(dst);
> }
> 
> Test results of copying one file, size 46M, from a nfs share to a local
> disk:
> 
> real    0m12.656s
> user    0m1.227s
> sys     0m0.087s
> 
> 
> Same program, now done in unbuffered system calls. Note that the program
> now is non-portable and more complex:
> 
> 
> #include <stdio.h>
> 
> #include <unistd.h>
> #include <sys/types.h>
> #include <sys/stat.h>
> #include <fcntl.h>
> 
> int main(int argc, char *argv[])
> {
> 	if (argc < 3)
> 	{
> 		fprintf(stderr, "Usage: %s <src> <dst>\n", argv[0]);
> 		return 1;
> 	}
> 
> 	int src = open(argv[1], O_RDONLY);
> 	int dst = open(argv[2], O_WRONLY | O_TRUNC);
> 	unsigned char data;
> 	while (read(src, &data, 1) == 1)
> 		write(dst, &data, 1);

Well, that was designed to fail.

    char data[512]; int n;
    while ((n=read(src, data, sizeof data))>0) write(dst, data, n);

> 	close(src);
> 	close(dst);
> }

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

[toc] | [prev] | [next] | [standalone]

#7971

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

[toc] | [prev] | [next] | [standalone]

#7981

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.

[toc] | [prev] | [next] | [standalone]

#7982

On 2011-07-08, China Blue Dolls <chine.bleu@yahoo.com> wrote:
> 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.

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 / usenet-nospam@seebs.net
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.

[toc] | [prev] | [next] | [standalone]

#7985

In article <slrnj1ea1m.25s3.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 <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.
> 
> How many are those?  I'm not sure I've ever seen a replacement of
> fopen() outside of newbie code.

Here's one: http://tcl.sourceforge.net/
Possibly another: http://www.python.org/download/source/

You should meditate on your own experience compared to random people.

> > And how often do people use a remote connection any more?
> 
> Pretty much constantly.  Do you know the word "server"?

Again your experience betrays you. 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.

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

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.

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

Do say.

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

I no longer work on Cyber 170s and 200s, SGIs, or Vaxes.

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

[toc] | [prev] | [next] | [standalone]

#7988

On 2011-07-08, China Blue Dolls <chine.bleu@yahoo.com> 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 / usenet-nospam@seebs.net
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.

[toc] | [prev] | [next] | [standalone]

#8005

China Blue Dolls <chine.bleu@yahoo.com> writes:
> In article <slrnj1ea1m.25s3.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 <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.
>> 
>> How many are those?  I'm not sure I've ever seen a replacement of
>> fopen() outside of newbie code.
>
> Here's one: http://tcl.sourceforge.net/
> Possibly another: http://www.python.org/download/source/
[...]

Those are languages other than C.  If those the best examples you
have, I don't think you're supporting your point very well.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#8016

In article <lnvcvcy0ao.fsf@nuthaus.mib.org>, Keith Thompson <kst-u@mib.org> 
wrote:

> China Blue Dolls <chine.bleu@yahoo.com> writes:
> > In article <slrnj1ea1m.25s3.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 <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.
> >> 
> >> How many are those?  I'm not sure I've ever seen a replacement of
> >> fopen() outside of newbie code.
> >
> > Here's one: http://tcl.sourceforge.net/
> > Possibly another: http://www.python.org/download/source/
> [...]
> 
> Those are languages other than C.  If those the best examples you
> have, I don't think you're supporting your point very well.

What language is the Tcl library written in?

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

[toc] | [prev] | [next] | [standalone]

#8018

China Blue Dolls <chine.bleu@yahoo.com> writes:
> In article <lnvcvcy0ao.fsf@nuthaus.mib.org>, Keith Thompson <kst-u@mib.org> 
> wrote:
>> China Blue Dolls <chine.bleu@yahoo.com> writes:
>> > In article <slrnj1ea1m.25s3.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 <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.
>> >> 
>> >> How many are those?  I'm not sure I've ever seen a replacement of
>> >> fopen() outside of newbie code.
>> >
>> > Here's one: http://tcl.sourceforge.net/
>> > Possibly another: http://www.python.org/download/source/
>> [...]
>> 
>> Those are languages other than C.  If those the best examples you
>> have, I don't think you're supporting your point very well.
>
> What language is the Tcl library written in?

As far as I can tell, most of the library appears to be written
in Tcl.  The language implementation appears to be in C.

Are you trying to make some point about C code that uses some kind
of replacement for fopen() rather than using fopen() itself?  If so,
please be more specific.  Posting the URLs for two large source
trees that may or may not contain something relevant is not helpful.

On the other hand, if you don't *want* to make your point clearly,
that's fine with me.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#8023

On 2011-07-08, Keith Thompson <kst-u@mib.org> wrote:
> China Blue Dolls <chine.bleu@yahoo.com> writes:
>> In article <slrnj1ea1m.25s3.usenet-nospam@guild.seebs.net>,
>>  Seebs <usenet-nospam@seebs.net> wrote:
>>> How many are those?  I'm not sure I've ever seen a replacement of
>>> fopen() outside of newbie code.

>> Here's one: http://tcl.sourceforge.net/
>> Possibly another: http://www.python.org/download/source/
> [...]

> Those are languages other than C.  If those the best examples you
> have, I don't think you're supporting your point very well.

Sort of.  Those are languages of which the most widely-used implementations
are indeed in C.  And they tend to replace stdio so they can do their own
magic.

Not sure I'd consider those very representative cases, though.

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
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.

[toc] | [prev] | [next] | [standalone]

#8028

In article <slrnj1frrm.2i1j.usenet-nospam@guild.seebs.net>,
 Seebs <usenet-nospam@seebs.net> wrote:

> On 2011-07-08, Keith Thompson <kst-u@mib.org> wrote:
> > China Blue Dolls <chine.bleu@yahoo.com> writes:
> >> In article <slrnj1ea1m.25s3.usenet-nospam@guild.seebs.net>,
> >>  Seebs <usenet-nospam@seebs.net> wrote:
> >>> How many are those?  I'm not sure I've ever seen a replacement of
> >>> fopen() outside of newbie code.
> 
> >> Here's one: http://tcl.sourceforge.net/
> >> Possibly another: http://www.python.org/download/source/
> > [...]
> 
> > Those are languages other than C.  If those the best examples you
> > have, I don't think you're supporting your point very well.
> 
> Sort of.  Those are languages of which the most widely-used implementations
> are indeed in C.  And they tend to replace stdio so they can do their own
> magic.

The Tcl library is written in C and intended to be used from C. It also includes 
an interpretter, but you can use the library without ever using the interpretter.

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

[toc] | [prev] | [next] | [standalone]

#8003

On 07/ 9/11 03:29 AM, China Blue Dolls wrote:
> 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.

Most of the time, most days.

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

Says who?

stdio is the best choice until proven otherwise.  Even in the small 
embedded world, stdio is the common channel for communicating with the 
outside world.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c

csiph-web