Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

fputc

0 views
Skip to first unread message

Yves Pelletier

unread,
Jul 17, 1998, 3:00:00 AM7/17/98
to
Hello all...

I have had a request from Christian to revert fputc to its
previous behaviour.

What it did before: insert an \r before every lone \n it
encountered.
What it does now: output characters as-is, without end-of-line
translation.

Which should it be? (I know this was discussed before, but
perhaps we can find a way to resolve this more decisively...)


Yves
__
When the trees are seen to be moving, the enemy is advancing.
Sun Tzu 9:20


Kristoffer Lawson

unread,
Jul 17, 1998, 3:00:00 AM7/17/98
to
On Fri, 17 Jul 1998, Yves Pelletier wrote:

> What it did before: insert an \r before every lone \n it
> encountered.
> What it does now: output characters as-is, without end-of-line
> translation.

I think the ANSI C standard is quite specific with this. \n does not
necessarily translate to directly to one character but means anything that
moves the cursor to the beginning of the next line. On DOS and related
systems this would be CRLF (some compilers I tested, however, didn't
operate in this way which was extremely annoying for porting software).
For MiNT we need to choose which we want and then stick with it.

- ---------- = = ---------//--+
| / Kristoffer Lawson | www.fishpool.com
+-> | se...@fishpool.com | - - --+
|-- Fishpool Creations Ltd - / |
+-------- = - - - = --------- /~setok/


Howard Chu

unread,
Jul 17, 1998, 3:00:00 AM7/17/98
to
In what context are you talking? I thought all stdio behavior was based on
the _binmode variable...

> -----Original Message-----
> From: Yves Pelletier [mailto:yp...@cam.org]
> Sent: Friday, July 17, 1998 5:00 AM
> To: MiNT mailing list
> Subject: fputc
>
>
> Hello all...
>
> I have had a request from Christian to revert fputc to its
> previous behaviour.
>

> What it did before: insert an \r before every lone \n it
> encountered.
> What it does now: output characters as-is, without end-of-line
> translation.
>

Michael Schwingen

unread,
Jul 18, 1998, 3:00:00 AM7/18/98
to
On Fri, Jul 17, 1998 at 08:00:18AM -0400, Yves Pelletier wrote:
> Which should it be? (I know this was discussed before, but
> perhaps we can find a way to resolve this more decisively...)

It depends:

If the file was opened in binary mode: do no translations.
If the file was opened in ASCII mode: write CR/LF

cu
Michael
--
Michael Schwingen, Ahornstrasse 36, 52074 Aachen


Yves Pelletier

unread,
Jul 21, 1998, 3:00:00 AM7/21/98
to
On Fri, 17 Jul 1998, Howard Chu wrote:

> In what context are you talking? I thought all stdio behavior was based on
> the _binmode variable...

The problem is with non-MiNT systems.

Quoting Christian,

"If a program do output via fputc() and you run it unter !MiNT
(plain TOS or MagiC) it produces wrong new-lines.

From a printf("hello\nhello\n") you get this:

hello
hello"

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.


Yves


Konrad Kokoszkiewicz

unread,
Jul 21, 1998, 3:00:00 AM7/21/98
to
> The problem is with non-MiNT systems.
>
> Quoting Christian,
>
> "If a program do output via fputc() and you run it unter !MiNT
> (plain TOS or MagiC) it produces wrong new-lines.
>
> >From a printf("hello\nhello\n") you get this:
>
> hello
> hello"
>
> 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.

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.

The question is what is more important: proper behaviour under MiNT or
perhaps under some non-MiNT systems.

Gtx,

--
Konrad M.Kokoszkiewicz
|mail: dr...@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.


Mikko Larjava

unread,
Jul 21, 1998, 3:00:00 AM7/21/98
to
On Tue, 21 Jul 1998, Konrad Kokoszkiewicz wrote:

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

Hhm... e.g. readline library doesn't work right with this change.
Pressing return at prompt only moves the cursor to next line it doesn't
move it to the beginning of the line. So things doesn't work alright with
all the MiNT things either. The other question is if it even should work
propely without kernels cr/nl translation which it normally takes off.


Howard Chu

unread,
Jul 21, 1998, 3:00:00 AM7/21/98
to
> >
> > 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.

Yves Pelletier

unread,
Jul 22, 1998, 3:00:00 AM7/22/98
to
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


Yves Pelletier

unread,
Jul 23, 1998, 3:00:00 AM7/23/98
to

I have put a copy of the old fputc.c in the patch directory of
my ftp site.

ftp://ftp.cam.org/users/ypell/MiNTlib-PL48/patches


Yves


0 new messages