🚀 go-pugleaf

In article <1990Oct13.204721.8027@maths.tcd.ie> tim@maths.tcd.ie (Timothy Murphy) writes:
>I was recently ... surprised to find that the compiler didn't like
>	fopen(filename, "rb");
>[it returned NULL, but worked after removing the "b" modifier].
>
>I think it's quite a common practice to give the "rb" and "wb"
>arguments for Unix/DOS compatibility.

Unix is the one system where you *don't* need it.  The "b" modifier is for the
benefit of non-Unix systems, like DOS and VMS.  The traditional pre-ANSI Unix
implementation doesn't scan the entire string, so "rb" would be equivalent to
"r".

>What does standard C say about it?

X3J11 standardized C, not Unix, and so they asserted that "r" opens a text
stream and "rb" opens a binary stream, as you were expecting.  If your vendor
claims ANSI conformance, you should flag this as a bug.  If not, then you
should encourage them to join the civilized world.

>And should the DECstation compiler have complained at compile-time,
>if it didn't understand the argument?

It *could* have.  But in all known implementations, fopen() is merely a
library routine, not a builtin; so all the compiler sees is a function call
whose second argument happens to be a string literal.  It's up to the run-time
library to interpret the string as a request for binary read.

(Similarly, the traditional implementation doesn't catch format mismatch in
printf() or scanf().  But this is such a common error that some vendors have
added appropriate compiler hooks to allow compile-time checking when the
format argument is a string literal.)

Karl W. Z. Heuer (karl@ima.isc.com or harvard!ima!karl), The Walking Lint
Followups to comp.std.c only.