fputc, asmtrans.ttp

[Yves Pelletier <ypell@cam.org>]

Hello all,

I took a look at the source for asmtrans.ttp, to find out how it
handles ends-of-lines.  Somewhat to my surprise, the code
actually takes steps to make sure it outputs Unix-style
end-of-lines.  So why do the *.s files come out with \r\n line
terminations anyway?  Here it is: 

The following command line, used in the MiNT makefile, produces
\r\n ends-of-lines in foo.s:

asmtrans.ttp -gas -o foo.s < foo.spp

Now this one, produces clean \n ends-of-lines, even if the input
file had \r\n's.  That is because we bypass asmtrans.ttp's
internal output routine, and go straight to stdout.

asmtrans.ttp -gas < foo.spp > foo.s

It turns out that when asmtrans.tpp is given an explicit output
file name, it uses fputs() to output the character strings to a
file.  fputs, in turn, calls fputc().  Now fputc comes from the
old Dlibs, and has a hack in it that automatically does 
\n --> \r\n conversion.  In effect, fputc was putting back the
\r characters that asmtrans had removed in the first place!  I
don't believe fputc should ever act as a filter, so I think I
will remove the conversion code from fputc.  Any objections? 

Question: do the assemblers used by PureC and Lattice C
handle Unix-style ends-of-line, or do they expect \r\n?

Yves