cr/lf conundrum

Earnie Boyd
Fri May 19 13:44:00 GMT 2000

--- DJ Delorie <> wrote:
> 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?

After investigating stdio.h I see that getc/putc are already prototyped as
functions.  The getc/putc macros are conditioned with `#ifndef lint' already. 
This could be modified to also condition __CYGWIN__ or give instructions to use
`-Dlint' in CFLAGS.


   Earnie Boyd: < >
            __Cygwin: POSIX on Windows__
Cygwin Newbies: < >
           __Minimalist GNU for Windows__
  Mingw32 List: < >
    Mingw Home: < >

Do You Yahoo!?
Send instant messages & get email alerts with Yahoo! Messenger.

More information about the Cygwin-developers mailing list