tim@maths.tcd.ie (Timothy Murphy) (10/14/90)
I was recently compiling the TeX PostScript driver program dvitops on a DECstation, and was surprised to find that the compiler didn't like fopen(filename, "rb"); It didn't object at compile-time, but simply failed to open the file (returning NULL). (There was no problem once all the "rb"'s and "wb"'s were changed to "r" and "w".) I think it's quite a common practice to give the "rb" and "wb" arguments for Unix/DOS compatibility. Is this relying on the compiler's generosity? What does standard C say about it? And should the DECstation compiler have complained at compile-time, if it didn't understand the argument? -- Timothy Murphy e-mail: tim@maths.tcd.ie
em@dce.ie (Eamonn McManus) (10/15/90)
In article <1990Oct13.204721.8027@maths.tcd.ie> tim@maths.tcd.ie (Timothy Murphy) writes: > I was recently compiling the TeX PostScript driver program dvitops > on a DECstation, > and was surprised to find that the compiler didn't like > fopen(filename, "rb"); Older Unix stdio implementations were only specified to take "r", "w", and "a" for the mode argument, each with a possible "+" appended. However, the implementation in fact just looked at the first character and at whether the second character was '+'. Apparently the Ultrix people decided that they would tighten up the checking, so where "rb" would be accepted before it is now rejected by Ultrix. This is unfortunate, because the ANSI C standard requires "rb" to mean open in binary rather than text mode, when there is a difference. > And should the DECstation compiler have complained at compile-time, > if it didn't understand the argument? That would require the compiler to recognise the fopen() function specially. Very few implementors would consider this to be worthwhile just for that check. Prior to ANSI C, there was no reason to suppose that a reference to fopen() would actually be resolved to the stdio function of that name.
meissner@osf.org (Michael Meissner) (10/15/90)
In article <1990Oct13.204721.8027@maths.tcd.ie> tim@maths.tcd.ie (Timothy Murphy) writes: | I was recently compiling the TeX PostScript driver program dvitops | on a DECstation, | and was surprised to find that the compiler didn't like | fopen(filename, "rb"); | It didn't object at compile-time, | but simply failed to open the file (returning NULL). | (There was no problem once all the "rb"'s and "wb"'s | were changed to "r" and "w".) | | I think it's quite a common practice to give the "rb" and "wb" | arguments for Unix/DOS compatibility. | Is this relying on the compiler's generosity? Actually it relies on the normal UNIX library not fully checking the string passed to fopen. Ultrix evidently does more stringent checking. | What does standard C say about it? The new options "rb", "wb", and "ab", etc. are required to be supported by anything that claims to be ANSI conformant. However, DEC doesn't currently claim ANSI conformance..... | And should the DECstation compiler have complained at compile-time, | if it didn't understand the argument? Few C compilers know about the precise arguments to fopen. In general, fopen is just another function (remember I/O is not built into the language, but is provided by the library -- C is not PASCAL or PL/1). If you have a fopen prototype, then the compiler would know that the second argument to fopen is a char *. -- Michael Meissner email: meissner@osf.org phone: 617-621-8861 Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142 Do apple growers tell their kids money doesn't grow on bushes?
karl@haddock.ima.isc.com (Karl Heuer) (10/15/90)
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.
bhoughto@cmdnfs.intel.com (Blair P. Houghton) (10/15/90)
In article <1990Oct13.204721.8027@maths.tcd.ie> tim@maths.tcd.ie (Timothy Murphy) writes: >(There was no problem once all the "rb"'s and "wb"'s >were changed to "r" and "w".) If your compiler claims ANSI conformance and does this, then it's broken. >Is this relying on the compiler's generosity? No, it's relying on ANSI X3.159-1989, section 4.9.5.3 The fopen Function, pp. 130, ll. 28-9. When did DEC get an ANSI compiler? --Blair "They still don't have an X X."
henry@zoo.toronto.edu (Henry Spencer) (10/16/90)
In article <1990Oct13.204721.8027@maths.tcd.ie> tim@maths.tcd.ie (Timothy Murphy) writes: >I think it's quite a common practice to give the "rb" and "wb" >arguments for Unix/DOS compatibility. >Is this relying on the compiler's generosity? >What does standard C say about it? It's relying on the compiler being standard, which yours obviously isn't yet. ANSI C says that those are legitimate forms, although on some systems they may be equivalent to "r" and "w". >And should the DECstation compiler have complained at compile-time, >if it didn't understand the argument? The compiler generally does not try to understand such strings and can't complain. They are interpreted at run time; to the compiler, it's just a character string. A compiler *could* try to check this, since the second argument to fopen is almost invariably a string constant, but I'm not aware of any that does. It would have been nice if the combination of fopen() and the program in question reported an error intelligently, so you could tell what was going on, but intelligent error reporting is very rare. -- "...the i860 is a wonderful source | Henry Spencer at U of Toronto Zoology of thesis topics." --Preston Briggs | henry@zoo.toronto.edu utzoo!henry