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 2 of 2 — ← Prev page 1 [2]

#8025

China Blue Dolls <chine.bleu@yahoo.com> writes:

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

Just about.  But "the cloud" and web based services looks like pushing
it back again.

All my current work expects to get streams of stuff in.  Even when you
write things to cope with character-by-character activities (suggesting
word completions for example) you are reading from HTTP GETs and sending
HTTP formatted blocks of results.

All of which fits the tty model to a T.

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

Obviously we program in very different domains.  What's nice is that C
lets us do that.
-- 
Online waterways route planner            | http://canalplan.eu
Plan trips, see photos, check facilities  | http://canalplan.org.uk

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

#8032

On Jul 8, 6:29 pm, China Blue Dolls <chine.b...@yahoo.com> wrote:
>
>
> I hate to break to you, but stdio is increasingly the interface of last resort.
>
Typically on a modern hosted system you've got programs which do
processing, and write to and from stdio. Then you've got programs with
graphical user interfaces which will use stdio for communicating with
backing store but not for communicating with the user. Then you've got
Internet aware programs that use stdio for spitting out html,
sometimes for backing store, but also use sockets for retrieving data
from the web, and may or may not have a GUI. Finally you've got
programs like the clipboard which use special OS protocols but which
the user expects to work with most programs.

Basically it's a mess and stdio is part of that mess. You use stdio
for gluing together different programs, but it's far less efficient
than calling subroutines, which sometimes matters and sometimes
doesn't. Non-technical users like to be protected from the console as
far as possible, technical users sometimes but not always prefer it
depending on the job in hand, sometimes stdio is semi-transparent to
networks, and often you do want to specify that data is to be stored
locally.
--
The Internet part of my mess
http://www.malcolmmclean.site11.com/www
(Most of the programs use stdio).

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

#8053

On Sat, 09 Jul 2011 06:55:08 -0700, Malcolm McLean wrote:

>> I hate to break to you, but stdio is increasingly the interface of last
>> resort.
>>
> Typically on a modern hosted system you've got programs which do
> processing, and write to and from stdio. Then you've got

Then you've got programs which do processing, and use low-level I/O
(open/read/write/close) or memory-mapped I/O.

For many of the GNU coreutils programs (i.e. classic Unix "filter"
programs), stdio is the interface of last resort. Even if they use
buffered I/O, they typically open() the file first then use fdopen() to
get a FILE* from the descriptor if they want it.

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

#8058

On Jul 10, 7:26 am, Nobody <nob...@nowhere.com> wrote:
>
> For many of the GNU coreutils programs (i.e. classic Unix "filter"
> programs), stdio is the interface of last resort. Even if they use
> buffered I/O, they typically open() the file first then use fdopen() to
> get a FILE* from the descriptor if they want it.
>
There's a slight difference with core programs.

It's a bit like the strdup() issue.
I normally write strdup like this

char *mystrdup(const char *str)
{
  char *answer = malloc(strlen(str) + 1);
  if(answer)
    strcpy(answer, str);
  return answer;
}

However if you write it like like this

char *superstrdup(const char *str)
{
  size_t len = strlen(str);
  char *answer = malloc(len + 1);
  if(answer)
    memcpy(answer, str, len+1);
  return answer;
}

compilers will often emit more efficient code.
It's not normally worth the bother, but if you are implementing a
library function, it is worth it.

Similarly with core utilities. The few microseconds you can shave off
file activities by using unbuffered, hand optimised IO becomes worth
it, because the utility is run many millions of times.
--
Play amino invaders!
http://www.malcolmmclean.site11.com/www

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

#7962

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

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

#8002

On 07/ 9/11 12:18 AM, James Kuyper wrote:
> 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.

Exactly my point, thank you.

-- 
Ian Collins

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

#8026

James Kuyper <jameskuyper@verizon.net> writes:

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

I've had the need for "create and open the file if it doesn't exist,
otherwise fail" and had to stick it in my "system specific bodges" bit.
Very useful if more than one instance of your program (or other programs
using the same file structure) could be running at once.
-- 
Online waterways route planner            | http://canalplan.eu
Plan trips, see photos, check facilities  | http://canalplan.org.uk

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

#7966

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

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

#7997

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

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web