Newsgroups: comp.sys.mac.programmer
Path: utzoo!utgpu!watserv1!watnow.waterloo.edu!jlee
From: jlee@watnow.waterloo.edu (Johnny Lee)
Subject: Re: THINK C 4.0 bug
Message-ID: <1991Feb1.051150.17238@watserv1.waterloo.edu>
Summary: Not really a bug
Keywords: THINK C 
Sender: daemon@watserv1.waterloo.edu
Organization: University of Waterloo
References: <DL5Lw2w163w@cs.fau.edu> <1991Jan31.172141.13662@cbnewsk.att.com>
Date: Fri, 1 Feb 91 05:11:50 GMT
Lines: 29

In article <1991Jan31.172141.13662@cbnewsk.att.com> ech@cbnewsk.att.com (ned.horvath) writes:
>From article <DL5Lw2w163w@cs.fau.edu>, by jeffb@cs.fau.edu (Jeffrey Boser):
>> during the decoder portion, i use
>>  putc(o, stdout);
>> to output a calculated integer (lower byte only).
>> 
>> but when o is equal to 10 (checked it while in debugger),
>> it outputs 13.  (checked from a hex dump of output file).
>> the stdout is redirected with a ccommand.
>> 
[Stuff deleted]
>	putc ('\n', stdout);
>and did you the favor of turning the (unix-like) newline into a 
>(mac-like) carriage return.

Well, if you are saving the output of stdout as well as
displaying it, there's not much you can do - unless you want to
modify the sources of the console.

The problem is that stdin, stdout and stderr are created as text streams.
What you want is a binary stream. The command freopen() is what you want
to be able to write stuff to stdout, saved to a file, without the
console modifying the values [remember to use "wb" in freopen()].
I believe there's another uudecoder available (on sumex?) which has the
similar problem. Mine works fine though. :-)

Johnny Lee
jlee@watnow.waterloo.edu
jlee@watnow.uwaterloo.ca
