Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT sourceware DOT cygnus DOT com>
List-Archive: <http://sourceware.cygnus.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT sourceware DOT cygnus DOT com>
List-Help: <mailto:cygwin-developers-help AT sourceware DOT cygnus DOT com>, <http://sourceware.cygnus.com/ml/#faqs>
Sender: cygwin-developers-owner AT sourceware DOT cygnus DOT com
Delivered-To: mailing list cygwin-developers AT sourceware DOT cygnus DOT com
Date: Fri, 19 May 2000 16:27:07 -0400
Message-Id: <200005192027.QAA20516@envy.delorie.com>
From: DJ Delorie <dj AT delorie DOT com>
To: cygwin-developers AT sourceware DOT cygnus DOT com
Subject: cr/lf conundrum


OK, I've been working on the CR/LF problem, and I've come down to a
problem that isn't easily solved:

	getc() and putc() are macros.

That means that part of the buffering system in stdio is in the
application, not the dll, so there's no way I can fix the application
to use the new scheme, which moves CR/LF conversions to the stdio
buffering layer (to fix ftell()).  That means that any existing
program that uses getc or putc (or putchar, fgetc, or any other macro
derivitive) is going to do binary I/O for those calls, no matter what.

The reason this is a big deal is because it affects terminal I/O too,
that is, you get stairstepped text:
	example
	        stair-stepped
	                      text

because there are no CR's to move the cursor back to the beginning of
the line.

There are a couple of things I can do to prevent this type of problem
in the future (namely, making getc/putc *not* be macros), but I can't
think of a good solution to handle existing applications.  I can think
of many hacks, but they all have drawbacks.

Ideas?