From: jmichel AT schur DOT institut DOT math DOT jussieu DOT fr (Jean Michel) Newsgroups: comp.os.msdos.djgpp Subject: Re: Bug in djgpp libc Date: 1 Jan 2001 17:24:47 +0100 Organization: A poorly-installed InterNetNews site Lines: 28 Message-ID: <92qb0f$17r$1@schur.institut.math.jussieu.fr> References: NNTP-Posting-Host: schur.institut.math.jussieu.fr Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: vishnu.jussieu.fr 978365904 8957 134.157.13.71 (1 Jan 2001 16:18:24 GMT) X-Complaints-To: Newsmaster AT jussieu DOT fr. NNTP-Posting-Date: 1 Jan 2001 16:18:24 GMT To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com In article , Eli Zaretskii wrote: > >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 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? Well, does not djgpp claim to be an environment which makes it easy to port Unix programs to DOS (even at the expense of doing a lot of contortions to implement stat accurately, for instance)? I claim that in the same way it should be the job of the libc low-level routines to detect that the output is to a console device, and do the appropriate thing (filter ^Z, whatever) so that no spurious error is returned, and that more programs can be ported painlessly. Best regards, Jean MICHEL