delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/2000/08/26/21:01:41

From: Radical NetSurfer <radsmail AT juno DOT com>
Newsgroups: comp.os.msdos.djgpp
Subject: printf, cprintf and CR/LF problem
Date: Sat, 26 Aug 2000 17:59:26 -0400
Message-ID: <s2fgqs8iobmdvbfrjfl2tfm57i2o9e2mov@4ax.com>
X-Newsreader: Forte Agent 1.8/32.548
X-No-Archive: yes
MIME-Version: 1.0
NNTP-Posting-Host: 216.202.140.94
X-Original-NNTP-Posting-Host: 216.202.140.94
X-Trace: 26 Aug 2000 18:02:23 -0400, 216.202.140.94
Lines: 24
X-Original-NNTP-Posting-Host: 64.31.79.51
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

Todays latest discoveries, with no work-around to date:

Apparently, 
  printf
 and
  cprintf

are immediately outputting a cr/lf, and scrolling, once it reaches the
line limit, before it may actually be necessary to do so (issue cr/lf
and scrolling).   Other screen I/O routines actually WAIT for the NEXT
line to actually begin printing, and then do NOT actually insert a
BLANK line (as if CR/LF is actually a part of the line itself)
(allowing all 80 characters of a standard text screen to be printed,
and seeing the CR/LF as simply going to the next line).

Is there any way to get this proper (and apparently expected) behavior
from printf, and cprintf, in DJGPP and other compilers?

Thanks!

/* Still waiting to learn what a 16-bit entity is called on a 32-bit
platform (since WORD has been made in an ambiguous term. */


- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019