OSDev.org

bochs says it's bogus memory... why don't i get an exception or something, or why doens't the kernel crash ???

That sounds extremely scary to me. This is not an x86 thing. this is a compiler thing.

Char (same way as 'int') are _signed_ numbers. When you write

the compiler should warn you the constant will be too big for the storage type.

Natively, the computer can only compare words of the same width (e.g. chars and chars, shorts and shorts, ints and ints, longs and longs, etc). Whenever you attempt to compare/move values between variables of different width, the system will _cast_ the value to the target type (or to the largest type for the purpose of comparison -- Solar, hit me back if i'm wrong here, will you ?)

That means when you write

what you actually tell the compiler to do is


since the pattern "FF" is "-1" for a char, it will be converted to
an int of value "-1" before comparison occurs (e.g. "FFFFFFFF").

So the code will eventually be compiled as


hope it makes it clearer.

You did query it after the kernel halted, not before? If you did then, yes the system should have page faulted.

I did clarify by saying "GCC 32bit aligns it to speed up access"

reading at inexistant physical memory usually returns "-1". under bochs, it also complains about "bogus memory". My guess is you *have* a page table entry for it (for some reason), but it's filled with garbage that sends the CPU to some memory that doesn't exist.

the best thing you could do is to cross-check the content of CR3, then of PDE and PTE accordingly to see if everything is *really* in place.

"x <addr>" inspect a virtual address and "xp <addr>" a physical address with bochs.

it works! at last ;D ;D

the problem was that it used for the pagetable the latest physical address, what caused to be no memory there. thanks everyone ;D

Nope. char doesn't behave like int, in this regard. Whether 'char' is signed or unsigned is "implementation defined", which means you can set your compiler to do either. Assuming signed char is commonplace, but by no means mandatory.

(Said the language lawyer, and withdraws to his cave again, madly mumbling and scribbling away on standard things...)



Just did so. You are right about the comparison thing though.

Note that the matter gets more tricky when variable parameter lists come into play. And:



...is still an invalid assumption.