gnu@hoptoad.uucp (John Gilmore) (03/27/88)
I was just reading over the standard trying to figure out the differences
between binary and text files and had a few realizations:
* Stdin, stdout, and stderr are assumed to be *text* files.
A program that does binary I/O on them is not portable. So, how does
one fix this?
* There seems to be *no way* to "reopen" these streams as
binary. E.g. how do I write a binary file to the current standard
output? Freopen will redirect stdout to a different named file, but I
just want binary treatment for the existing output file (e.g. the one
specified by the user when they ran "a.out >foo").
PS: In the process I found that, since stdout is a *text* file,
fflush() should not write record boundaries on it. Standard I/O is
allowed to screw around with text files (too much, in my opinion - see
section 4.9.2), but it's not allowed to insert newlines at random
places. Though it is not at all clear what is allowed to happen if you
exceed the system's line length limit, which there seems to be no way
to determine, except that it can't be less than 254.
--
{pyramid,ptsfa,amdahl,sun,ihnp4}!hoptoad!gnu gnu@toad.com
"Watch me change my world..." -- Liquid Theatrechris@mimsy.UUCP (Chris Torek) (03/27/88)
In article <4250@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes: > * There seems to be *no way* to "reopen" [stdin and stdout] as >binary. I believe this is the case. I thought at one point that freopen((char *)NULL, "rb", stdin); was supposed to do that sort of thing, but apparently that was just a proposal; it never made it into any draft. (This seems to me a not unreasonable way to do it. Systems that do not have modes need only say if (name == NULL && stream_is_open(stream)) return (stream); while those that do can do whatever is required at system startup and file open time to figure out what modes are permissible and to retain whatever state is needed to set them. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
gwyn@brl-smoke.ARPA (Doug Gwyn ) (03/27/88)
In article <4250@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes: >There seems to be *no way* to "reopen" these streams as binary. That's right; on POSIX-conforming systems it makes no difference but on oddball OSes it could. However, on such OSes it seems unlikely that processes would be nicely piped together anyway, or that it would make sense for the application to tell the system what type of file it was dealing with when the system had actually set it up for the process. There was a proposal for freopen((char*)0,mode,stream) to effect a change of mode on an open stream, but several implementors thought that switching modes in midstream could be difficult to support on some systems.
ado@elsie.UUCP (Arthur David Olson) (03/29/88)
> > There seems to be *no way* to "reopen" these streams as binary. > > There was a proposal for freopen((char*)0,mode,stream) to effect > a change of mode on an open stream, but several implementors > thought that switching modes in midstream could be difficult to > support on some systems. Couldn't freopen simply return ((FILE *) 0) in such cases, much as localtime is allowed to return -1 if local time can't be determined? -- olson@ncifcrf.gov "...that lucky ol' Sun ain't got nothin' to do..."
djones@megatest.UUCP (Dave Jones) (03/29/88)
in article <4250@hoptoad.uucp>, gnu@hoptoad.uucp (John Gilmore) says: > > I was just reading over the standard trying to figure out the differences > between binary and text files and had a few realizations: > > * Stdin, stdout, and stderr are assumed to be *text* files. > A program that does binary I/O on them is not portable. So, how does > one fix this? > > ... On a Unix system, one writes a buffering package for raw bytes, something akin to stdio, using write(). Since you don't need printf and scanf, it's no big deal. Unfortunately, I have seen one implementation of C (IBM System 370) which does not have write(). Or if they do, they don't document it.
gwyn@brl-smoke.ARPA (Doug Gwyn ) (03/29/88)
In article <8036@elsie.UUCP> ado@elsie.UUCP (Arthur David Olson) writes: >Couldn't freopen simply return ((FILE *) 0) in such cases, much as >localtime is allowed to return -1 if local time can't be determined? Sure; but then what good does it to to specify the facility if portable code couldn't rely on it working?
ado@elsie.UUCP (Arthur David Olson) (03/30/88)
> > Couldn't freopen simply return ((FILE *) 0) in such cases, much as > > localtime is allowed to return -1 if local time can't be determined? > > Sure; but then what good does it to to specify the facility if > portable code couldn't rely on it working? Same as with localtime: it provides a standardized way for accessing the capability *when it is available.* -- olson@ncifcrf.gov "...that lucky ol' Sun ain't got nothin' to do..."
karl@haddock.ISC.COM (Karl Heuer) (03/30/88)
In article <8036@elsie.UUCP> ado@elsie.UUCP (Arthur David Olson) writes: >> > There seems to be *no way* to "reopen" these streams as binary. >> There was a proposal for freopen((char*)0,mode,stream) to effect >> a change of mode on an open stream, but several implementors >> thought that switching modes in midstream could be difficult to >> support on some systems. > >Couldn't freopen simply return ((FILE *) 0) in such cases, much as >localtime is allowed to return -1 if local time can't be determined? That's time(), not localtime(). Let's consider three classes of machines. Those on which text and binary streams are identical (POSIX); those on which such a mode-change is impossible (probably because the mode is set in concrete when the file is first opened); and those on which it is neither trivial nor impossible. The proposed functionality is only useful on the third class. Are there any such implementations? (Where do MSDOS and VMS fall?) Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint
dhesi@bsu-cs.UUCP (Rahul Dhesi) (03/30/88)
In article <3221@haddock.ISC.COM> karl@haddock.ima.isc.com (Karl Heuer) writes: [re mode change] >(Where do MSDOS and VMS fall?) Since MS-DOS was designed by obtaining a weighted harmonic mean of CP/M and UNIX, it behaves as follows. In UNIX tradition, the operating system itself does not distinguish between text and binary files. In the tradition of CP/M, however, each line in a text file is terminated by a CR LF sequence, but this convention is enforced by programs that use text files (including utilities supplied with MS-DOS) and not by the file system. When a C program reads a text file, the runtime library routines strip out any CR characters, thus reading the same sequence of characters that would be read on a UNIX system. When writing a text file, a CR character is added before each LF is written. (Note: The correct way to perform the newline conversion would be to use a state machine. Then isolated CR characters, which occur in files that include overprinting controls for line printers, would not be stripped out. It is not clear if any runtime library actually goes to this trouble; seeks would disturb any state information maintained anyway.) Thus the mode of a file (whether text or binary) exists only as a mode bit in the runtime library of a C program. The file mode is therefore relevant only to a C program and not, for example, to an assembly language program or a BASIC program. Common C libraries supply a macro or a function that will change between text and binary modes for open files. Oh, by the way, many programs that were originally written for CP/M and ported for MS-DOS use a control Z character in text files to mark end-of-file. MS-DOS utilities will recognize the control Z and do weird things with it, but they do not themselves write a control Z to mark end of file, since MS-DOS, like UNIX, takes the simple (yet unusual) point of view that a file ends wherever it ends. The MS-DOS console driver, if operating in cooked mode, freaks out when a control Z is written to the console, and refuses to write any more until the EOF condition is cleared. (Can you imagine, a console driver with an EOF condition occurring during *output* to a video terminal?) This is a bug, though it was probably originally meant to be a feature that would prevent trailing garbage from appearing on the screen when an old format text file was typed. VMS C does not normally need any mode change for open files. The default type of a file opened from a C program is stream-LF, which uses records terminated by linefeeds, and does not distinguish between text and binary formats at all, acting like UNIX and POSIX files. Unfortunately, when a C program is executed, stdout is by default not a stream-LF file, and it's not clear that this can be changed by the user. Since I/O redirection under VMS is rather painful, it will seldom be the case that a program will want to do a seek on its standard output anyway. Even when the standard output of a C program is redirected to a file, that file is opened for output in some weird mode which is not stream-LF. (I consider this a bug.) The type of this file cannot be changed while it is open. This is why problems occur, and presumably why running my "Hello world" program under batch caused strange behavior. -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi
gnu@hoptoad.uucp (John Gilmore) (04/01/88)
karl@haddock.ISC.COM (Karl Heuer) wrote: > In article <8036@elsie.UUCP> ado@elsie.UUCP (Arthur David Olson) writes: > >> > There seems to be *no way* to "reopen" these streams as binary. > >> There was a proposal for freopen((char*)0,mode,stream) to effect > >> a change of mode on an open stream, but several implementors > >> thought that switching modes in midstream could be difficult to > >> support on some systems. > Let's consider three classes of machines. Those on which text and binary > streams are identical (POSIX); those on which such a mode-change is impossible > (probably because the mode is set in concrete when the file is first opened); > and those on which it is neither trivial nor impossible. > The proposed functionality is only useful on the third class. Are there any > such implementations? (Where do MSDOS and VMS fall?) Let me give you a specific example to chew on. I have written a bunch of programs for manipulation of image files in the Sun rasterfile format. The particular format is not important to know except that it is binary. Now, these programs are set up to accept a rasterfile on stdin, manipulate it, and produce a new one on stdout, so you can do things like: <image scale .5 .5 | clip 0 40 300 300 | bwdither | lpr -v This really works on Unix, and it would be pretty easy to make these work on any system that could support binary files as stdin/stdout, (and had a shell that would make pipes, like MSDOS or Unix), but not if the standard doesn't tell me and those implementers a good way for me to say "please sir, don't translate CR to LF on stdin for me, just let me at the bytes"... [As mentioned, MSDOS has this capability; as on Unix, "text" versus "binary" is all in the application's head (the problems arise because the default text format is not the one assumed by C programs from Unix). Atari's TOS is the same way. I'm not sure about AmigaDOS or the MacOS. VMS has already been explained to be *unable* do handle this, but I don't care if my stuff runs on VMS anyway.] So I'm not asking for a *requirement* that all systems be able to handle binary I/O on stdin/out/err, just a method for requesting it where possible, to encourage portability to systems that are capable of it. -- {pyramid,pacbell,amdahl,sun,ihnp4}!hoptoad!gnu gnu@toad.com "Don't fuck with the name space!" -- Hugh Daniel
dsill@NSWC-OAS.arpa (Dave Sill) (04/01/88)
>(Where do MSDOS and VMS fall?)
Around here they generally fall in the trash.karl@haddock.ISC.COM (Karl Heuer) (04/02/88)
In article <2500@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: >[In VMS] the default type of a file opened from a C program is stream-LF, >which uses records terminated by linefeeds, and does not distinguish between >text and binary formats at all, acting like UNIX and POSIX files. The fact that it's called "stream-LF" (as distinct from "stream-CR" or just "stream") suggests that the newlines which terminate the records have some significance to the OS. Is it legal, for example, to write 70000 characters without a newline? If not, this doesn't seem like an acceptable format for binary mode. Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint
ok@quintus.UUCP (Richard A. O'Keefe) (04/02/88)
In article <4296@hoptoad.uucp>, gnu@hoptoad.uucp (John Gilmore) writes: > karl@haddock.ISC.COM (Karl Heuer) wrote: > > In article <8036@elsie.UUCP> ado@elsie.UUCP (Arthur David Olson) writes: > > >> > There seems to be *no way* to "reopen" these streams as binary. > <image scale .5 .5 | clip 0 40 300 300 | bwdither | lpr -v > This really works on Unix, and it would be pretty easy to make these > work on any system that could support binary files as stdin/stdout, > (and had a shell that would make pipes, like MSDOS or Unix), but not if > the standard doesn't tell me and those implementers a good way for me > to say "please sir, don't translate CR to LF on stdin for me, just let > me at the bytes"... If UNIX needed this facility, and if it used "b" to indicate binary mode, FILE *binin = fdopen(fileno(stdin), "rb"); FILE *binout= fdopen(fileno(stdout),"wb"); /* use bin_in, bin_out instead of stdin, stdout */ would do the job. Would this work in MSDOS? Instead of having a way of switching the mode, why not ask for two more "standard" streams: binin and binout, where systems which don't need a distinction between text and binary would identify them with stdin and stdout, systems where switching is possible would switch as necessary, and systems where only one method of connexion was allowed would have all I/O on the "wrong" connexions return EOF, and systems where either method was allowed but not both would pick it up from the first use.
dhesi@bsu-cs.UUCP (Rahul Dhesi) (04/03/88)
In article <3295@haddock.ISC.COM> karl@haddock.ima.isc.com (Karl Heuer) writes: [about VMS stream-LF files] >The fact that it's called "stream-LF" (as distinct from "stream-CR" or just >"stream") suggests that the newlines which terminate the records have some >significance to the OS. Is it legal, for example, to write 70000 characters >without a newline? If not, this doesn't seem like an acceptable format for >binary mode. Yes, a VMS C program can write any number of characters before writing a newline, and it works, and it can all be read back. VMS does handle records of arbitrary length in stream-LF files, SO LONG AS ALL ACCESS IS THROUGH THE VMS C LIBRARY. Things break down, however, when such a file is manipulated in any other manner, as is shown by the following program. -----cut here----- #include <stdio.h> /* testing VMS stream-LF format */ #define HOWMUCH 2000 /* how much to write as a single record */ #define FNAME "junk.dat" /* what to call the file */ main() { FILE *f; int i; int c; f = fopen (FNAME, "w"); if (f == NULL) perror("write"); for (i = 0; i < HOWMUCH; i++) fputc ('x', f); fputc ('\n', f); /* terminates stream-LF record *whew* */ fclose (f); /* now read file and dump to screen */ f = fopen (FNAME, "r"); if (f == NULL) perror ("read"); for (i = 0; i < HOWMUCH + 1; i++) { c = fgetc (f); fputc (c, stdout); } } -----cut here----- This program writes a 2000-character record to junk.dat, then reads junk.dat and sends it to the screen. I ran it both interactively and under batch. (a) Interactively: What is printed on the screen by the program is what I expected: 2000 'x' characters. But when I gave the VMS command "type junk.dat" I got a QIO error, presumably because the VMS "type" command can't handle 2000-character records. (b) Under batch: The output from the program as shown in the batch log was not 2000 'x' characters followed by a newline. Instead, I saw lines of 512 'x' characters. Clearly, a newline was being forced after 512 characters at most. When the batch file did "type junk.dat", a QIO error occurred again. -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi
scjones@sdrc.UUCP (Larry Jones) (04/03/88)
In article <3295@haddock.ISC.COM>, karl@haddock.ISC.COM (Karl Heuer) writes: > In article <2500@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: > >[In VMS] the default type of a file opened from a C program is stream-LF, > >which uses records terminated by linefeeds, and does not distinguish between > >text and binary formats at all, acting like UNIX and POSIX files. > > The fact that it's called "stream-LF" (as distinct from "stream-CR" or just > "stream") suggests that the newlines which terminate the records have some > significance to the OS. Is it legal, for example, to write 70000 characters > without a newline? If not, this doesn't seem like an acceptable format for > binary mode. Yes, you can write as many characters as you want without a newline - you don't even need one at the end of the file. The only significance of the "stream-LF" designation is to allow the file system to simulate a record structured file meaningfully. Since most VMS programs are only capable of handling record structure files (stream file being relatively new), this is of immeasurable value. ---- Larry Jones UUCP: uunet!sdrc!scjones SDRC MAIL: 2000 Eastman Dr., Milford, OH 45150 AT&T: (513) 576-2070 "When all else fails, read the directions."
hydrovax@titan.nmt.edu (M. Warner Losh) (04/03/88)
In article <3295@haddock.ISC.COM> karl@haddock.ima.isc.com (Karl Heuer) writes: +In article <2500@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: +>[In VMS] the default type of a file opened from a C program is stream-LF, +>which uses records terminated by linefeeds, and does not distinguish between +>text and binary formats at all, acting like UNIX and POSIX files. +The fact that it's called "stream-LF" (as distinct from "stream-CR" or just +"stream") suggests that the newlines which terminate the records have some +significance to the OS. Is it legal, for example, to write 70000 characters +without a newline? If not, this doesn't seem like an acceptable format for +binary mode. In VMS it is legal (VMS 4.4 C 2.2). There are a few system utilities that will gronk and die when you try to use this format. I think that this is a small problem with i/o quotas not being set up correctly, but never did look into it more deeply. I got around the problem by not having to use that particular system utility :-) +Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint -- bitnet: losh@nmt.csnet M. Warner Losh warner@hydrovax.nmt.csnet ! Don't know if this works, let me know. csnet: warner@hydrovax.nmt.edu uucp: ...{cmcl2, ihnp4}!lanl!unmvax!nmtsun!warner%hydrovax
wes@obie.UUCP (Barnacle Wes) (04/05/88)
In article <3295@haddock.ISC.COM>, karl@haddock.ISC.COM (Karl Heuer) writes: | In article <2500@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: | >[In VMS] the default type of a file opened from a C program is stream-LF, | >which uses records terminated by linefeeds, and does not distinguish between | >text and binary formats at all, acting like UNIX and POSIX files. | | The fact that it's called "stream-LF" (as distinct from "stream-CR" or just | "stream") suggests that the newlines which terminate the records have some | significance to the OS. Is it legal, for example, to write 70000 characters | without a newline? If not, this doesn't seem like an acceptable format for | binary mode. VMS "stream" files have a block size of 1 char, so you can write out whatever you want (as long as you don't overflow the device). -- /\ - "Against Stupidity, - {backbones}! /\/\ . /\ - The Gods Themselves - utah-cs!utah-gr! / \/ \/\/ \ - Contend in Vain." - uplherc!sp7040! / U i n T e c h \ - Schiller - obie!wes
brianc@cognos.uucp (Brian Campbell) (04/05/88)
In article <4250@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes:
! I was just reading over the standard trying to figure out the differences
! between binary and text files and had a few realizations:
!
! * Stdin, stdout, and stderr are assumed to be *text* files.
! A program that does binary I/O on them is not portable. So, how does
! one fix this?
Is this a portable concept?
! * There seems to be *no way* to "reopen" these streams as
! binary. E.g. how do I write a binary file to the current standard
! output? Freopen will redirect stdout to a different named file, but I
! just want binary treatment for the existing output file (e.g. the one
! specified by the user when they ran "a.out >foo").
As Doug Gwyn pointed out, this makes no difference on POSIX-conforming
systems. Under DOS, however, both the Borland and Microsoft C libraries
include a setmode(int fd, unsigned mode) function. The mode parameter is
pretty much the same as that of creat() with the addition of two other
masks: O_BINARY and O_TEXT.
--
Brian Campbell uucp: decvax!utzoo!dciem!nrcaer!cognos!brianc
Cognos Incorporated mail: POB 9707, 3755 Riverside Drive, Ottawa, K1G 3Z4
(613) 738-1440 fido: (613) 731-2945 300/1200, sysop@1:163/8ado@elsie.UUCP (Arthur David Olson) (04/10/88)
> If UNIX needed this facility, and if it used "b" to indicate binary mode, > FILE *binin = fdopen(fileno(stdin), "rb"); > FILE *binout= fdopen(fileno(stdout),"wb"); > /* use bin_in, bin_out instead of stdin, stdout */ > would do the job. Would this work in MSDOS? Whether or not it works in MSDOS, it wouldn't work in draft proposed ANSI C (which lacks an "fdopen" function). -- ado@ncifcrf.gov ADO is a trademark of Ampex.
ok@quintus.UUCP (Richard A. O'Keefe) (04/12/88)
In article <8042@elsie.UUCP>, ado@elsie.UUCP (Arthur David Olson) writes: [ Citation omitted by Olson] > > If UNIX needed this facility, and if it used "b" to indicate binary mode, > > FILE *binin = fdopen(fileno(stdin), "rb"); > > FILE *binout= fdopen(fileno(stdout),"wb"); > > /* use bin_in, bin_out instead of stdin, stdout */ > > would do the job. Would this work in MSDOS? > > Whether or not it works in MSDOS, it wouldn't work in draft proposed ANSI C > (which lacks an "fdopen" function). That's hardly news: the point of the discussion was precisely that the ability to do binary I/O on stdin/stdout was something that some people needed and didn't appear to be available in dpANS. The point of my message was to suggest that instead of switching a stdio stream between several modes it might suffice to be able to attach new streams to existing ports.
dhesi@bsu-cs.UUCP (Rahul Dhesi) (04/12/88)
In article <865@cresswell.quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes: >...the point of the discussion was precisely that the >ability to do binary I/O on stdin/stdout was something that some people >needed and didn't appear to be available in dpANS. ANSI can't change this for you. ANSI is obliged to humor existing broken software environments. But you aren't! Let your buying dollar make a statement. -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi
gwyn@brl-smoke.ARPA (Doug Gwyn ) (04/14/88)
In article <2605@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: >ANSI can't change this for you. ANSI is obliged to humor existing broken >software environments. X3J11 decides what to do about variations among operating systems on a case-by-case basis. We could require some way to obtain binary streams for stdin/stdout if we thought it sufficiently useful AND if we could figure out a viable method for doing so. P.S. My personal opinion, not an X3J11 official statement.
amen@quequeg.UUCP (Bob Amen) (04/15/88)
From article <7678@brl-smoke.ARPA>, by gwyn@brl-smoke.ARPA (Doug Gwyn ): > In article <2605@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: >>ANSI can't change this for you. ANSI is obliged to humor existing broken >>software environments. > > [...] We could require some way to obtain binary > streams for stdin/stdout if we thought it sufficiently useful AND if > we could figure out a viable method for doing so. > > P.S. My personal opinion, not an X3J11 official statement. Perhaps I'm a bit confused here but it's always been my impression that UNIX was designed to make no distinction between binary and ASCII (say) data. For those of us using UNIX systems to do science, the ability to read binary data (transparently) is a necessity. Without that we lose most of what I find UNIX great for...like being able to write small useful programs that operate on data and fit them together with pipes and tees. (There are other useful things as well.) Why is this a problem now? I've been following this discussion but have not yet heard a compelling reason to break one of the greatest advantages of UNIX. -- Bob Amen (amen@quequeg.UUCP) (+1 301 338-6329) Chesapeake Bay Institute/The Johns Hopkins University
henry@utzoo.uucp (Henry Spencer) (04/24/88)
> ... it's always been my impression > that UNIX was designed to make no distinction between binary and ASCII > (say) data... Why is this a problem now? ... The key point here is that X3J11 is standardizing C, not Unix. X3J11 must define a standard that is implementable on non-Unix systems, some of which insist that text and binary i/o are very different animals. -- "Noalias must go. This is | Henry Spencer @ U of Toronto Zoology non-negotiable." --DMR | {ihnp4,decvax,uunet!mnetor}!utzoo!henry
gwyn@brl-smoke.ARPA (Doug Gwyn ) (04/24/88)
In article <281@quequeg.UUCP> amen@quequeg.UUCP (Bob Amen) writes: > Perhaps I'm a bit confused here but it's always been my impression >that UNIX was designed to make no distinction between binary and ASCII > ... >Why is this a problem now? I've >been following this discussion but have not yet heard a compelling reason >to break one of the greatest advantages of UNIX. You misunderstand. UNIX need not (and undoubtedly will not) change in this respect. The discussion was about what should be specified in the forthcoming ANSI C standard, which applies across ALL operating systems, including some that would have great difficulty supporting a UNIX-like notion of file. Such systems often need to treat text files and binary files in different ways. The "b" specifier appended to an fopen() mode requests that the stream be handled as binary; stdin/stdout/stderr are required to be initially open as text streams. On UNIX it makes no difference, but on some systems this can pose a problem. We were careful to permit text and binary streams to be indistinguishable on systems where that was appropriate; the forthcoming IEEE Std 1003.1 (POSIX) requires this behavior, which is compatible with proposed ANSI C.