Xref: utzoo comp.std.c:3761 comp.text.tex:3369 Path: utzoo!attcan!uunet!wuarchive!julius.cs.uiuc.edu!apple!snorkelwacker!paperboy!meissner From: meissner@osf.org (Michael Meissner) Newsgroups: comp.std.c,comp.text.tex Subject: Re: DVItoPS on DECstation Message-ID: Date: 15 Oct 90 15:19:50 GMT References: <1990Oct13.204721.8027@maths.tcd.ie> Sender: news@OSF.ORG Organization: Open Software Foundation Lines: 39 In-reply-to: tim@maths.tcd.ie's message of 13 Oct 90 20:47:21 GMT 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?