RE: fputc

[Yves Pelletier <ypell@cam.org>]

On Tue, 21 Jul 1998, Howard Chu wrote:

>  ... it sounds like a bad port of the Unix programs, not a
> library feature that needed changing. Whenever porting a Unix
> program to a non-Unix system, you have to examine all uses of
> stdio and determine whether it is dealing with a text file or
> a binary file, and tweak the fopen's accordingly. 
> The library already has the capability to modify EOL sequences
> appropriately, but it's up to the calling application to use
> fopen correctly. 

Ok.

(...)
> 
> Since this is a MiNTlib that we're discussing, I guess you
> could make the argument that proper behavior under MiNT is the
> only concern. But I would rather argue that the library is
> already capable of behaving correctly in all environments; it
> is up to the person porting a Unix app to use the library
> correctly in the first place.  I believe that the old MiNTlib
> behavior was both sufficient and correct, relying on UNIXMODE
> etc. If fputc today is now hardcoded to never convert \n into
> \r\n, even if the stdio stream is in text mode as opposed to
> binary mode, then I consider this library to now be broken. 

I agree.  I was slowly coming to realize my mistake, and now you
have put it clearly into the light. I will upload a patch
reverting to the old behaviour (could be a few days).  Or in the
meantime you could simply extract fputc from PL47.

Thanks (and sorry...)

Yves