Date: Mon, 1 Jan 2001 16:27:59 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: Jean Michel cc: djgpp AT delorie DOT com Subject: Re: Bug in djgpp libc In-Reply-To: <92pr3q$12a$1@schur.institut.math.jussieu.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On 1 Jan 2001, Jean Michel wrote: > >> No space left on drive (ENOSPC) > > > >That's because the DOS/Windows console driver returns EOF when you write > >the Ctrl-Z character to it in cooked mode. Ctrl-Z is a kind of > >``software end-of-file'' marker in DOS. There's nothing DJGPP can do with > >that. > > Perhaps return a more accurate (unique?) error condition? Which one? There's no mnemonic for such problems in any other DOS/Windows compiler I know about. And Unix compilers don't know anything about this brain damage either. ENOSPC is returned because the console device refuses to take any more data (the _write primitive tries twice before it gives up). > The fact is that the interpreter does not know to which file handle it > is writing to at that stage, it is just echoing characters read from a > text file which happens to contain the above (probably after having been > modified by some strange DOS editor). The program can know that it writes to a console device: it just needs to call isatty() on the handle. It can also filter out ^Z characters if stdout is connected to the console. Finally, it can remove trailing ^Z from input after it reads it. (Such removal will happen automatically if the input is read in text mode.) Would that solve the problem? > Also I point out that no > error message is returned if the ^Z is not followed very soon by a \n. That's because of buffering, I think. A newline caused the stdout buffer to be flushed.