RE: fputc

["Howard Chu" <chu@platinum.com>]

> >
> > This feature caused on the patch which you have added to
> fputc() on 4. Jan
> > 1998. Before you have add this patch the behaviour of \n
> depends on UNIXMODE:
> > if it was not set you got only \n but if you set UNIXMODE=b you
> got \r\n.
> > Why do you have change this thing?? "
> >
> > End quote
> >
> > The way fputc was before, (systematically inserting \r before
> > all lone \n), still seems wrong to me...  but I would revert to
> > if it were the only way to go.

But if it was indeed controlled by the UNIXMODE setting, then it was at
least user-definable, instead of hard-coded to behave only one way. I think
honoring the UNIXMODE setting still makes sense.
>
> I can sort of answer why this patch was done: because Unix programs didn't
> like the CR/LF sequence and for example asmtrans.ttp kept inserting CRLF
> anywhere it could. What wasn't tolerated by the gas 2.5.1.

This may be true, but 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.
>
> The question is what is more important: proper behaviour under MiNT or
> perhaps under some non-MiNT systems.

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.
>
> Gtx,
>
> --
> Konrad M.Kokoszkiewicz
> |mail: draco@mi.com.pl                  | Atari Falcon030/TT030/65XE |
> |http://www.orient.uw.edu.pl/~conradus/
>
> ** Ea natura multitudinis est,
> ** aut servit humiliter, aut superbe dominatur (Liv. XXIV,25)
> *************************************************************
> ** U pospolstwa normalne jest, ze albo sluzy ono unizenie,
> ** albo bezczelnie sie panoszy.
>
>