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: <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 , 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