🔒 Locked

Writing in binary mode

Started by Ziphnor Jun 11, 2002 at 3:47 PM 11 replies 350+ views

Original Post

Jun 11, 2002 at 3:47 PM

Im in the middle of writing some code that can handle saving stuff to a binary file. On the lowest level, im writing simple data types using the write method of the fstream object. I do it like this

file is a fstream* opened in binary mode, val is what we are saving) file->write((char*)&val,sizeof(val)); This works fine, but im not 100% sure the result is correct. For example if i write an int, the result is 4-bytes of data as it should be. But lets say i write an integer with value 1, viewing this with a binary file viewer shows this: 00000001 00000000 00000000 00000000 I was kind of expecting something like: 00000000 00000000 00000000 00000001 If the int increases in size to for example 256(ie moving into the next byte) i get this: 00000000 00000001 00000000 00000000 Where i was expecting: 00000000 00000000 00000001 00000000 Am i being stupid or something? [edited by - ziphnor on June 11, 2002 4:49:18 PM]

IndirectX

Jun 11, 2002 at 3:51 PM

x86 processors store the least significant byte of the word first, and the least significant word of dword first. So what you''re seeing is normal.

intransigent-seal

Jun 11, 2002 at 3:52 PM

In files numbers are stored with their byte order reversed (ie least significant byte first). So what you saw was perfectly normal.

EDIT:: D'oh - you beat me to it.

John B

[edited by - JohnBSmall on June 11, 2002 4:53:16 PM]

felonius

Jun 11, 2002 at 4:02 PM

Just for completeness. In techno-speak we say that x86 processors are "little endian" processors which means that you store the least significant byte at the lowest adress.

The opposite "big-endian" is what you seemed to expect.

Qw3r7yU10p!

Jun 11, 2002 at 6:28 PM

the little-endians and big-endians were two groups of people in gullivers travels. one lot thought that the right way to eat an egg was from the little end first. the big endians knew this were wrong and that you should eat the big end of the egg first.

i follow the gourd.
i follow the sandal.

etc

DerekSaw

Jun 11, 2002 at 8:36 PM

And remember, the endian thingie has nothing to do with the indians.

BS-er

Jun 11, 2002 at 8:49 PM

Someone correct me if I''m wrong. Internally, your Intel CPU represents a 1 as: 10000000 00000000 00000000 00000000.

When you view the 32 bit value using some viewer, it takes 8 bits at a time and displays each 8 bit chunk using the common convention of LSB last. That is why the first 8 bits are displayed as 00000001.

Ziphnor

Jun 12, 2002 at 3:59 AM

I didnt think it was an endian thing because then i would have expected
10000000 00000000 00000000 00000000
as being one.

But i can see that if the binary file viewer uses the "normal" way of showing a binary number(ie the least significant byte last, at least thats the way i consider normal because its the way we normally write numbers in other bases), as BS-er suggested, and it reads one byte at a time(which it does as you can tell by the grouping) then i guess it explains it.

Thanks guys.

Dean Harding

Jun 12, 2002 at 4:19 AM

What you''re seeing is an effect of the endian-ness of Intel CPUs.

There is no distinction with the "endian-ness" of bits in a byte. This is because a byte is actually the smallest thing you can work with, so the "endian-ness" of the bits is not relevant.

When you look at an int in the debugger, it displays it in big-endian order (e.g, it might be 01 00 00 00 in memory, but it''s displayed as 0x00000001 in the debugger) because that''s how we generally write numbers.

codeka.com - Just click it.

DerekSaw

Jun 12, 2002 at 4:32 AM

quote:
Original post by BS-er
Someone correct me if I'm wrong. Internally, your Intel CPU represents a 1 as: 10000000 00000000 00000000 00000000.

When you view the 32 bit value using some viewer, it takes 8 bits at a time and displays each 8 bit chunk using the common convention of LSB last. That is why the first 8 bits are displayed as 00000001.

I'm not sure of this.. but in memory (and also files), the byte that contain the LSB come first.
eg:


DWORD a = 1;
                       1st byte   2nd byte   3rd byte   4th byte
                      ---------  ---------  ---------  ---------
Then in memory it is: 0000 0001  0000 0000  0000 0000  0000 0000
Sample memory addres: 0xBAD0001  0xBAD0002  0xBAD0003  0xBAD0004

[edited by - DerekSaw on June 12, 2002 5:33:27 AM]

felonius

Jun 12, 2002 at 5:11 AM

quote:
Original post by DerekSaw
I'm not sure of this.. but in memory (and also files), the byte that contain the LSB come first.

Absolutely correct. Endianness is relevant both in files, and in memory.

By talking about "internal in the CPU" you probably refer to the the CPU registers. These a not numberede/ordered so in that case endian-ness is not relevant.

[edited by - felonius on June 12, 2002 6:12:17 AM]

Ziphnor

Jun 12, 2002 at 5:16 AM

quote:

is no distinction with the "endian-ness" of bits in a byte.

Oh, so the "endian-ness" only decided the order of the bytes, not the bits(its been some time since i read that book on computer org. by tannenbaum

, so
00000001 00000000 00000000 00000000
is actually how an x86 computer stores an integer with value 1?

[edited by - ziphnor on June 12, 2002 6:29:48 AM]

Dean Harding

Jun 12, 2002 at 5:47 AM

quote:
Original post by Ziphnor
Oh, so the "endian-ness" only decided the order of the bytes, not the bits(its been some time since i read that book on computer org. by tannenbaum , so
00000001 00000000 00000000 00000000
is actually how an x86 computer stores an integer with value 1?

That''s right. If you think of a byte as an atomic unit (which it is, really), then it all makes sense.

codeka.com - Just click it.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.