🚀 go-pugleaf

In article <danpop.824525964@rscernix>, danpop@mail.cern.ch says...

>In the above paragraph.  The "low-level I/O functions" means essentially
>read/write.

That's right. I'm sorry. If that implies a comparison to the stdio routines,
then either you're reading it wrong or I was ambiguous. I'll take the hit
there. This whole thing was written as a response to someone asking a simple
question. The other responses I read were unsatisfactory. "Uh, I think it
has to do with UNIX compatibility", "fopen is buffered, open isn't", "fopen
is ANSI, open isn't". While all of these responses have some validity, they
don't give any feel for what the routines are good for.
I tried to respond in a straightforward manner, aiming primarily at the newer 
C programmer. My point that the low level routines offer excellent control 
to the programmer is a valid one. That this control is especially useful for 
binary files is also valid.
If you were writing a relational database or the input system for a lexical 
analyzer, which routines would you use? It's likely your answer differs from
mine. IMO, the standard C buffered (stdio) routines are a poor choice for 
either of these applications. If memory serves me, UNIX lex is written using 
the stdio routines, and that's fine. It's just not the way I'd do it. 

>True (in Unix, probably false on other platforms) but irrelevant.  There
>are no I/O needs that can be satisfied by one set of functions and not
>by another, unless we start talking about Unix-specific features
>(pipes, sockets, select()).

The original question was something to the effect of, "What is the difference 
between fopen and open and when should I use one over the other?". Are you 
saying I should have answered with, "They are functionally identical. There 
is no difference between them, whatsoever. Always use fopen(), PERIOD!!!".

>The stdio buffering is a red herring, because it can be always disabled, if it 
>isn't needed.

That's true. But if you're going to disable it, why not use the other routines? 
They're smaller. I guess portablity would be a valid reason. The stdio routines 
are ANSI and the others aren't. 

>In my <stdio.h> file, the constant BUFSIZ is 512. 

>Aha, I see where the magical value 512 came from.  The systems I'm working
>on have BUFSIZ set to values between 1024 (mostly BSD-based Unices) and 
>32768 (OpenVMS).  So, your claim that <stdio.h> sets the size of the
>buffer to 512 bytes is bogus.  BTW, even 512 is a humongous size for a
>single density 8" floppy disk, which needs to read four sectors to fill
>such a buffer.

This has an extemely condescending feel to it. Aha? Magical value? 
Your claim that <stdio.h> sets the size of the buffer? The clouds
have parted. I see clearly now. Dan has bestowed upon me the titles
C NEWBIE and UNIX Illiterate. 
BUFSIZ is in <stdio.h>. To say that the size of the buffer is set **IN**
the stdio.h file is not wrong or misleading. Not by any stretch of the
imagination. But you managed anyway. Since this thread is running in
both the c.l.c and msdos.programmer groups, I used the value most DOS 
compilers use. 

>Huh???  Where did I imply that setvbuf changes the _default_ buffer size.
> Snip...
>Care to mention a few examples?  Unix has had block devices for as long
>as I can remember.

Sorry, Dan. Just teasing you a little bit. Trying to get your goat, as it 
were. In retrospect, not a very constructive thing to do during a serious 
debate on the merits of open() vs. fopen(). :)

Again,sorry Dan. It just seemed like you were bragging about UNIX and 
putting down DOS (god forbid). I was hurt and offended (not really).
DOS is inferior to UNIX in almost every respect. Why isn't UNIX the
most dominant OS in the world? 

-John