The include_bytes! macro bugs

[zhangxuan2011]

I tried this code:

const DEFAULT_FONT_DATA: &[u8] = include_bytes!("../../fonts/default.bmf");     // I'm sure that file exists and it is correct!

This includes a Bitmap font file. Lately I'm making up an operating system, and i got the exact value from the serial, and converted them as ASCII character, but it is different from the origin one.

Meta

rustc --version --verbose:

rustc 1.89.0-nightly (4d08223c0 2025-05-31)
binary: rustc
commit-hash: 4d08223c054cf5a56d9761ca925fd46ffebe7115
commit-date: 2025-05-31
host: x86_64-unknown-linux-gnu
release: 1.89.0-nightly
LLVM version: 20.1.5

[moyanj]

We are confident that this method of extracting data is error-free.
Moreover, we calculate the MD5 value directly in the memory, which is different from the original file.

[jieyouxu]

Please provide a complete reproducer. In particular, does this happen for a smaller toy binary file? Is there a complete example we can look at?

Additionally, what happens if you also try to read the file with e.g. std::fs::read and then compare the contents? How large is "../../fonts/default.bmf"?

[moyanj]

This binary file is only 1MB in size. I have tried to calculate its MD5 value using Python's "open" function, but the result is different from what it should be.

[lukaslueg]

If you can, provide the file, and the hash you get from memory and via external tools

[moyanj]

default.bmf.zip

rust：
python:

This presents a very strange issue. Some of the data is the same, but some of it is different.

[moyanj]

Also, I'm trying to write a replication code. This program runs in a bare-metal environment, is booted by grub (multiboot2), has entered long mode, and uses a memory allocator and memory paging written by ourself.

[moyanj]

This is our repository, 'bmf' branch have our debug code. (Some document and comment is Chinese)

[jieyouxu]

Are you cross-compiling to x86_64-unknown-none?

[moyanj]

yes

[hkBst]

This program runs in a bare-metal environment, ..., and uses a memory allocator and memory paging written by ourself.

Could a bug in your allocator or paging impl produce what you are observing?

[zhangxuan2011]

This program runs in a bare-metal environment, ..., and uses a memory allocator and memory paging written by ourself.

Could a bug in your allocator or paging impl produce what you are observing?

Well, I'm sure that there's no problem, because I have tested Vec and String, all's normal.

Besides, If there's something wrong about the mapping, the code that write something to framebuffer won't be succeed.