Binary File I/O and ^M

[andy]

Hi,

What are the annoying ^M put at newlines when a text file is used in
binary mode?

I've written a file compression / decompression program using huffman
encodings. The algorithms work- On an input text file, It reads &
encodes and the file produced can be decoded back into the original.
Then I modified it to read any generic file to compress by reading in
binary mode. It compresses and decompresses well, except that ^M comes
after each line in the decompressed version.

Any suggestions?

Thanks,

andy

 

[red floyd]

Hi,

What are the annoying ^M put at newlines when a text file is used in
binary mode?

I've written a file compression / decompression program using huffman
encodings. The algorithms work- On an input text file, It reads &
encodes and the file produced can be decoded back into the original.
Then I modified it to read any generic file to compress by reading in
binary mode. It compresses and decompresses well, except that ^M comes
after each line in the decompressed version.

I assume you're working on a Windows platform.

Windows uses a CR-LF combo as its line terminator. In text mode,
they're collapsed to a single newline (\n). But for compression, you
*must* read in binary mode, which means that CR-LF translation doesn't
occur.

 

[andy]

Hi- thanks. I actually just found that out running the same code on a
linux box. On this compression note- I'm still running into a problem I
believe involving my buffering. To read a binary file byte-by-byte, I'm
putting it in an unsigned char* buffer. I noticed that when the chars
were signed, negative int values were sometimes assigned. I'm trying to
resolve bytes to their ascii equivalent and that was causing problems.
Will the unsigned char* fix this? I think I may be loosing some data
somewhere. Thanks...

 

[Jim Langston]

Hi- thanks. I actually just found that out running the same code on a
linux box. On this compression note- I'm still running into a problem I
believe involving my buffering. To read a binary file byte-by-byte, I'm
putting it in an unsigned char* buffer. I noticed that when the chars
were signed, negative int values were sometimes assigned. I'm trying to
resolve bytes to their ascii equivalent and that was causing problems.
Will the unsigned char* fix this? I think I may be loosing some data
somewhere. Thanks...

An unsigned char is 0 to 255.
a signed char is -128 to 127
So any char greater than 127 would show up as negative as a signed char.

Yes, changing it to unsigned char will at least show you the values 0 to 255
instead of negative values. Although the actual bit values won't change.