jeffb@cs.fau.edu (Jeffrey Boser) (01/31/91)
While writing a uudecoder, i have stumbled on what seems to be a bug in the ANSI libraries. 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. any ideas? .....Jeff reply to weissd@tuna.cs.fau.edu, as my mailer is down.
ech@cbnewsk.att.com (ned.horvath) (02/01/91)
From article <DL5Lw2w163w@cs.fau.edu>, by jeffb@cs.fau.edu (Jeffrey Boser): > While writing a uudecoder, i have stumbled on > what seems to be a bug in the ANSI libraries. > > 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. > > any ideas? > > > .....Jeff > reply to weissd@tuna.cs.fau.edu, as my mailer is down. This isn't a bug, it's a feces -- er, feature. putc thinks you coded putc ('\n', stdout); and did you the favor of turning the (unix-like) newline into a (mac-like) carriage return. I suppose you might try fwrite() (I haven't, so no promises). =Ned Horvath=
minich@unx2.ucc.okstate.edu (Robert Minich) (02/01/91)
by jeffb@cs.fau.edu (Jeffrey Boser): | While writing a uudecoder, i have stumbled on | what seems to be a bug in the ANSI libraries. | | 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. | | any ideas? Sure. Open the file as binary if you want to write binary values in there! Look in the code for fopen.c, especially the replace(), to see what is happening. Change that fopen() to something like fopen(dest_fname, "wb"); and everything should work out. Also note that when you create a file without specifying binary mode, its type is TEXT while binary files are '????'. -- |_ /| | Robert Minich | |\'o.O' | Oklahoma State University| "I'm not discouraging others from using |=(___)= | minich@d.cs.okstate.edu | their power of the pen, but mine will | U | - "Ackphtth" | continue to do the crossword." M. Ho
jlee@watnow.waterloo.edu (Johnny Lee) (02/01/91)
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
niko@iastate.edu (Schuessler Nikolaus E) (03/04/91)
>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. > >any ideas? Yep. Unix uses a 0x0a (10) as an end of line and the mack uses a 0x0d to remain compatible, it does you a "favor" and automatically translates it for you. This is great if you are just writing/reading textfiles but it really sucks when you are writing binary. (THis is one of the many problems when porting Unix code to THINK) To solve this problem, you can do one of two things: 1) Use FOpen, Fclose and make your own putC & buffering routines 2) open the file with "wb" (i.e. fp=fopen("file.out","wb")) the 'b' indicates binary writing do no translating on unix you can get away without the 'b' so most people don't put it in.... Hope that helps.... --