The C code writes two integer to a binary file called "integer.bin".



I use format-hex cmd-let in PowerShell to hexdump the 8-byte "integer.bin".

The results is quite awkward, for 0x1234, it is " 34 12 00 00", but for 0x12345678, the "34 12" is not on the left-hand size, it is becoming as "78 56 34 12"..... No wonder I pening, pening kepala when doing my disassembler (passing the 32-bit integer as 64-bit parameter).


Can someone know explain? Are you also new to this?

By the way, there is no way to save integer to file in Python, either text or byte mode only, means have to convert number to string then save to file, in Python.

x86 is little endian.

Lower order of a byte stored in lower address space.

It has been a long debate between little or big endian, but I found little endian makes more sense. Because we can easily read a 64bits / 32 bits data without even knowing their size from the same address space.

For 0x1234:

In memory, the least significant byte is 34, and the most significant byte is 12.
When written to the file in binary format, the bytes are written in little-endian order.
Therefore, the hexdump shows 34 12 00 00, with the least significant byte 34 appearing first.

For 0x12345678:

In memory, the least significant byte is 78, and the most significant byte is 12.
When written to the file in binary format, the bytes are written in little-endian order.
Therefore, the hexdump shows 78 56 34 12, with the least significant byte 78 appearing first.


--

To save int only can save to text, binary

This post has been edited by cytyler: May 24 2023, 08:18 AM

walao, still got people play with c/c++? I know those who are good at C and C++ already above 40

Thanks to both for you reply. Some how I cannot make my C code work to write 64-bit integer to file.

Can you show how this long integer will be store in binary file: 0x0000001234567890

Or demonstrate any number in 64-bit integer, preferably with leading zero.

Thanks once again!

This post has been edited by Tullamarine: May 24 2023, 08:24 AM

I just show example by modifying a bit from tutorial code only, I do C#, not C/C++, hehe.

@WongGei is good in C++. Last time I and my colleague used Symbian C++ in early 2000, yes, we are old already, in our 40s.

#include <stdio.h>

int main()
{
unsigned long long long_integer = 0x0000001234567890;
FILE *fptr;

fptr = fopen("C:\\Users\\BOO\\Projects\\integer.bin", "wb");


fwrite(&long_integer, sizeof(unsigned long long), 1, fptr);

fclose(fptr);

return 0;
}

Run your C++ code in a big endian CPU like PowerPC

Or use the Big Endian directive __BIG_ENDIAN

nice, I learn C too but not talented with programming, hard to get all the things connected, gave up and become hardware guy :X

Thanks for the brilliant code.

I got this output:


I think @jibpek is right, lower order byte at lower address.


That will be a nice discovery. But I don't have any big endian CPU.

BTW, I think you're right about this:

x86 is little endian.

Lower order of a byte stored in lower address space.

Thanks!

Sorry I didn't read your question properly earlier, and didn't answer properly as well.

Your intentions is not about writing in big or little endian. You only would like to write the 64bits integer.

Besides, the processor directive given earlier is only to determine the endian, not to write in particular order.

Generating code against the CPU architecture will have huge performance impact.

It is good to ask questions, not only sharing my limited knowledge.

There are many teachers / sifu here who know better than me. Without asking, I won't know so many know answer to difficult question.

Thanks all.

IMHO, most of the info should be able to find from computer architecture theories.

Such an interesting questing. Allow me to share some info and a suggestion.

1. 64 bit unsigned integer or uint64 minimum value = 0 and max (2^64)-1
2. format-hex tool is available in MS Windows Power tools to display input as hexadecimal values.
3. The solution requires saving data as binary, and looks like another app will pick it up.
4. Without a C compiler at hand, can imagine how little endian will result, Better still, accessed compiler at https://www.onlinegdb.com/online_c_compiler#

Suggestion:
1. Store the integer in a fixed length to allow consistency of value retrieval
2. Working on top of code by @ cytyler, storing of values can be demonstrated



Output



Hope it helps.

an unsigned long long is 8 bytes, where did the 0xC2 come from?

This is the result from @tboxmy code :

demointeger.bin (16 bytes)

90 78 56 34 12 00 00 00 90 78 56 34 12 00 00 00

Don't know why (and how) to get the different result.

tboxmy

1. I dont have a PC with C compilers anymore...sigh! The online Compiler in use is https://www.onlinegdb.com/online_c_compiler# where I suspect it compiles to UTF.
2. When compile with LANG or LC_ALL default on Linux would be LANG=C. However, where LANG=en_US.UTF-8 then the hex values will differ as what I have shown. LC_TYPE value is connected too, need to check if you plan to use utf8 (which is widely used on global wide applications).
3. If you execute/run this a.out or binary, it should display the unicode as shown in attachment.
4. The unicode should display as shown by E2 98 A0, where you can refer at https://www.utf8-chartable.de/unicode-utf8-...rt=9728&names=-



Lots of this is just off my mind. Do read up for actual reasons.

This post has been edited by tboxmy: Jun 16 2023, 06:35 PM

Using the online hex viewer, https://www.scadacore.com/tools/programming...-hex-converter/

Attached is the output, and how that would have shown 0x0000001234567890 in its utf-8 instead of ansi ascii.
Hope that helps.

This post has been edited by tboxmy: Jun 17 2023, 09:43 PM

after read carefully, is the format-hex add additional characters.

The first line should be the "original hex" and follow by formatted hex / text.

The demointeger.bin should be 16 bytes.

This online hex viewer show the file content :

HexEd.it - Browser-based Online and Offline Hex Editing
https://hexed.it/