Writing single bits to a file

[riva]

I am developing a compression program. Is there any way to write a
data to file in the form of bits, like write bit 0 then bit 1 and then
bit 1 and so on ....

[riva]

Well, what if I have just 19 bytes to write that means 2 chars and 3
bits!

[mstorkamp]

On Oct 26, 3:42 pm, riva <ra.ravi....@gm ail.comwrote:

Well, what if I have just 19 bytes to write that means 2 chars and 3
bits!

Ah, no. That means 19 chars and 0 bits. But what's your point? I
create a 1 byte file on my computer and it take 4,096 bytes on my hard
disk (plus room for file name, creation date, etc.)

[Eric Sosman]

(When you reply to a Usenet post, please quote enough
context to make your reply meaningful as a stand-alone
message. People don't always follow a discussion serially
from its start, and someone whose first encounter with a
thread is something like -- well, like what you've written
below -- will have a hard time discovering what the topic
is, and are likely to ignore it. Thus, you risk depriving
yourself of their expertise. For those just tuning in, riva
asked how to write individual bits to a stream.)

riva wrote On 10/26/07 16:42,:

Well, what if I have just 19 bytes to write that means 2 chars and 3
bits!

I think you mean "bits," not "bytes." And that's why
I wrote

>[...] At the
end, you may need to provide a few extra bits to fill
up the final character.

.... in the part you didn't quote. Is there something in
my sentence that you find confusing?

--
Er*********@sun .com

[Don Bruder]

In article <11************ **********@v23g 2000prn.googleg roups.com>,
riva <ra*********@gm ail.comwrote:

Well, what if I have just 19 bytes to write that means 2 chars and 3
bits!

(Assuming you actually meant 19 BITS, rather than 19 BYTES...)

Then stuff the three leftover bits into a third byte, pad that byte with
5 bits of your choice (personally, I'd go with zeroes, but that's just
me) and write it.

Considering that every currently-in-use OS uses the concept of "blocks",
"chunks", or "clusters" as the smallest possible unit for disk I/O, with
each of them being made up of some multiple of 128 bytes, it's
incredibly unlikely that "saving" 5 bits is going to be meaningful in
any realistic situation.

--
Don Bruder - da****@sonic.ne t - If your "From:" address isn't on my whitelist,
or the subject of the message doesn't contain the exact text "PopperAndShado w"
somewhere, any message sent to this address will go in the garbage without my
ever knowing it arrived. Sorry... <http://www.sonic.net/~dakiddfor more info

[Joe Wright]

riva wrote:

Well, what if I have just 19 bytes to write that means 2 chars and 3
bits!

I assume you mean 19 bits. You will have to write 3 bytes (24 bits) to
get your 19 onto the stream.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[Keith Thompson]

Don Bruder <da****@sonic.n etwrites:

In article <11************ **********@v23g 2000prn.googleg roups.com>,
riva <ra*********@gm ail.comwrote:

>Well, what if I have just 19 bytes to write that means 2 chars and 3
bits!

(Assuming you actually meant 19 BITS, rather than 19 BYTES...)

Then stuff the three leftover bits into a third byte, pad that byte with
5 bits of your choice (personally, I'd go with zeroes, but that's just
me) and write it.

Considering that every currently-in-use OS uses the concept of "blocks",
"chunks", or "clusters" as the smallest possible unit for disk I/O, with
each of them being made up of some multiple of 128 bytes, it's
incredibly unlikely that "saving" 5 bits is going to be meaningful in
any realistic situation.

Sure, but it's not just a matter of saving space. The size of a file
(i.e., the number of bytes that have been written to it) can be an
important piece of information.

Under many operating systems, the size of a file is *recorded* as an
exact number of bytes, even if the physical size on disk is a multiple
of some larger block size. (However, the C standard doesn't guarantee
this; binary files can be padded at the end with null characters.)

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Tor Rustad]

riva wrote:

I am developing a compression program. Is there any way to write a
data to file in the form of bits, like write bit 0 then bit 1 and then
bit 1 and so on ....

The way this can be done in C compression SW, is if you provide your own
bit level I/O functions. However, in standard C those I/O functions need
to commit no less than chunks of size CHAR_BIT to a file, which is at
least an 8 bit object.

Standard practice is to pad the last character, just like we do in
communication or encryption SW. For details, look up a data compression
book, or ask in a data compression news group.

--
Tor <torust [at] online [dot] no>

"Technical skill is mastery of complexity, while creativity is mastery
of simplicity"

[Eric Sosman]

Keith Thompson wrote:

[...]
Sure, but it's not just a matter of saving space. The size of a file
(i.e., the number of bytes that have been written to it) can be an
important piece of information.

That's really not much help for the O.P.'s situation:
He's working on some kind of compression program, which can
generate a stream of output bits that doesn't "chunk" neatly
into an integral number of bytes. No file system I've ever
heard of can record a file length of 10007 bits. And it
gets worse: Some of the best compressors encode their output
in fractions of bits; if a file length of 10007 bits is bad,
a length of 10006.59029663+ bits is *really* bad!

See Walter Roberson's response.

--
Eric Sosman
es*****@ieee-dot-org.invalid

[Malcolm McLean]

"Don Bruder" <da****@sonic.n etwrote in message

Considering that every currently-in-use OS uses the concept of "blocks",
"chunks", or "clusters" as the smallest possible unit for disk I/O, with
each of them being made up of some multiple of 128 bytes, it's
incredibly unlikely that "saving" 5 bits is going to be meaningful in
any realistic situation.

Create thousands of such files, then tar them. See if you can detect a
difference between ten thousand 128 byte files and ten thousand 18-byte
files.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm