mikew@wheeler.wrcr.unr.edu (Mike Whitbeck) (07/27/89)
HELP !
I seem to get extra \r's from putchar()!!!! (or getchar()?)
I am using MWC 3.0 to port BR's splay compression program to the
ST. The program works fine under UNIX(SUN) and IDRIS (PE7300)
but on the ST I get extra 0x0D's (\r) in the output!
I put a counter in bit_output() immediately after the putchar()
(see below) and the loop is executed the correct no. of
times (e.g. N times but the file written contains more than
N bytes the extra bytes are 0x0D's).
[ To get the unsplay program to work I had to replace getchar()
with Cnecin(). Typically
splay < rawbinary > splaycompressed
unsplay < splaycompressed > rawbinary
This makes for smaller files than unix compress when working
with raw binary (poorer performance with ASCII files). ]
{I am using Mark William's C 3.0 and their msh.prg (a shell)}.
WHAT'S WRONG?
-------------------partial listing------------------------
/*
Splay Tree Compression
from: "Application Of Splay Trees To Data Compression"
by Douglas W. Jones, Communications of the ACM, August 1988
implemented in C by Bodo Rueskamp, <br@unido.uucp>
*/
/* splay tree compress */
#include <stdio.h>
int left[257], right[257], up[514];
static int bitnum = 0;
void bit_output(bit)
int bit;
{
static int byte = 0;
byte = (byte << 1) | bit;
++bitnum;
if (bitnum == 8) {
putchar(byte); <--------- main output from here
/* a counter placed here indicates the correct no. of passes
through this loop, the bytes written are also correct except for
a few extra 0x0D's interspersed */
byte = 0;
bitnum = 0;
}
}
...
stuff deleted for brevity
...
main()
{
int c;
putchar(0x1f); <------ magic number ok
putchar('S'); <------ magic number ok
initialize();
while ((c = getchar()) != EOF)
compress(c); <----- calls bit_output() to write
compressed data to stdout
..... stuff deleted....
return(0);
}koreth@panarthea.sun.com (Steven Grimm) (07/27/89)
In article <2829@tahoe.unr.edu> mikew@wheeler.UUCP (Mike Whitbeck) writes: >HELP ! >I seem to get extra \r's from putchar()!!!! (or getchar()?) On the ST, the end-of-line code is \r\n, not just \n as it is on UNIX. In order to output valid text files, C libraries translate \n to \r\n on output, and back the other way on input. Most C compilers on the ST let you pass a "b" modifier to in the second parameter of fopen(); this tells the compiler to skip its I/O translation. For instance, you'd say fp = fopen("filename", "wb"); Hope that helps. --- This message is a figment of your imagination. Any opinions are yours. Steven Grimm Moderator, comp.{sources,binaries}.atari.st sgrimm@sun.com ...!sun!sgrimm
woodside@ttidca.TTI.COM (George Woodside) (07/27/89)
In article <2829@tahoe.unr.edu> mikew@wheeler.UUCP (Mike Whitbeck) writes: >HELP ! >I seem to get extra \r's from putchar()!!!! (or getchar()?) >I am using MWC 3.0 to port BR's splay compression program to the >ST. The program works fine under UNIX(SUN) and IDRIS (PE7300) >but on the ST I get extra 0x0D's (\r) in the output! This is speculative, but I haven't seen any other suggestions: putchar and getchar are macros. They expand to putc(c,stdout) and getc(stdin), respectively. Both stdin and stdout are already opened as ASCII files when your program begins execution. The insertion of 0x0D into your data streams is most likely due to the high level handler attempting to add a carriage return (0x0D) when it sees a line feed (0x0A) in the stream. You can eliminate this by opeing binary input and output files (use "rb" or "wb" as the second parameter in the fopen() call), and use the putc and getc calls directly with the appropriate file handle. -- *George R. Woodside - Citicorp/TTI - Santa Monica, CA *Path: ..!{philabs|csun|psivax}!ttidca!woodside
mikew@wheeler.wrcr.unr.edu (Mike Whitbeck) (07/28/89)
In article <33978@grapevine.uucp> koreth (Steven Grimm) writes: ^In article <2829@tahoe.unr.edu^ mikew@wheeler.UUCP (Mike Whitbeck) writes: ^^HELP ! ^^I seem to get extra \r's from putchar()!!!! (or getchar()?) ^ ^On the ST, the end-of-line code is \r\n, not just \n as it is on UNIX. ^In order to output valid text files, C libraries translate \n to \r\n ^on output, and back the other way on input. ^ ^Most C compilers on the ST let you pass a "b" modifier to in the second ^parameter of fopen(); this tells the compiler to skip its I/O translation. ^ ... ^Hope that helps. ^ ^sgrimm@sun.com ...!sun!sgrimm Actually I am not getting the \r\n pair just the \r and somewhat randomly sprinkled throughout the file. A la UN*X I planned to use the splay program as a filter using stdin and stdout. Maybe I can write a scratch file fopen'd as per your sugesstion and then cat the scratch file to stdout via Pexec or execvec(). Thanks for the reply.