By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
455,433 Members | 1,797 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 455,433 IT Pros & Developers. It's quick & easy.

Binary File I/O and ^M

P: n/a
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

Nov 22 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a
andy wrote:
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.

Nov 22 '05 #2

P: n/a
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...

Nov 22 '05 #3

P: n/a
"andy" <an************@gmail.com> wrote in message
news:11**********************@g49g2000cwa.googlegr oups.com...
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.
Nov 22 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.