🚀 go-pugleaf

In article <4kinqm$hnt@eng_ser1.erg.cuhk.hk>, khtsang@cs.cuhk.hk writes:
> I'm a good man (mfchan@cs.cuhk.hk) wrote:
>>    char block[82];
>>    fp2 = fopen("fool", "r+b");
>>    writeblock(fp2, 0, OVERFILE, block);
> 
> One more thing...  What is your platform??  There's no "r+b" mode for
> fopen on unix systems...  Default mode is binary for all files.

More precisely, Unix makes no distinction between text and binary
modes.  However, there's no need to remove the "b" from the mode
string in fopen() calls on Unix machines.  Putting the "b" there
documents your program's intentions, and makes the program
portable to non-Unix machines.  All copies of fopen() that I'm
aware of under Unix will quietly ignore the "b", since it makes a
distinction which Unix is blissfully unaware of.  (ANSI C says
that "b" is legal in an fopen mode string, so it's required to be
either honored or quietly ignored, but as it happens pre-ANSI
copies of fopen() under Unix typically ignored unrecognized
characters at the end of fopen mode strings, too.)

The original poster's problem was probably that fopen() failed;
"r+b" mode does not create the file if it does not exist.
It's also possible that something down inside writeblock()
(the definition of which I didn't see) was improperly written.

					Steve Summit
					scs@eskimo.com