OSDev.org

hometue wrote:Looks trippy...except I can still read the text. Also on closer inspection the image does have the text "Ghost", but in a ghost-like manner. Is the pun intended?

Hehe well, that big "Ghost" text you see there is just the text-only logo of Ghost taken from the website, and painted on a smaller window thats behind the window that has much text. Windows have a little transparency, so thats what comes out

forgot to dereference a pointer for a while loop.
while(str != '\0')
\|/
while(*str != '\0')

I got this the other day...

The cause? A missing variable name meant that what should have been "(var & MASK)" became "( & MASK)". That meant that a file was read into completely the wrong place in memory. (I was working on implementing memory-mapped files.)

mallard wrote:The cause? A missing variable name meant that what should have been "(var & MASK)" became "( & MASK)". That meant that a file was read into completely the wrong place in memory.

Are you still not using warnings? Any decent compiler would warn you about using a pointer in place of an integer and vice versa. Also, traditionally only macro names consist of all capitals.

alexfru wrote:
Are you still not using warnings? Any decent compiler would warn you about using a pointer in place of an integer and vice versa. Also, traditionally only macro names consist of all capitals.

MASK is a constant, so is capitalised (it's C++, so constants really are constant.) The full code included casts e.g. "(char*)((uint32_t)var & MASK)", so with "var" missing, generated no warnings. The line is supposed to get the address of the start of the page that "var" (a pointer) points at.

mallard wrote:MASK is a constant, so is capitalised (it's C++, so constants really are constant.) The full code included casts e.g. "(char*)((uint32_t)var & MASK)", so with "var" missing, generated no warnings.

Ouch!

mallard wrote:

alexfru wrote:
Are you still not using warnings? Any decent compiler would warn you about using a pointer in place of an integer and vice versa. Also, traditionally only macro names consist of all capitals.

MASK is a constant, so is capitalised (it's C++, so constants really are constant.) The full code included casts e.g. "(char*)((uint32_t)var & MASK)", so with "var" missing, generated no warnings. The line is supposed to get the address of the start of the page that "var" (a pointer) points at.

It would generate you an error if you used proper c++ casts instead of the c ones. Also constants in c++ are constants, not macros, and it's macros that are typically capitalised, not constants.

Griwes wrote:
It would generate you an error if you used proper c++ casts instead of the c ones. Also constants in c++ are constants, not macros, and it's macros that are typically capitalised, not constants.

It seems there are more nitpickers in a semi-humours thread than there are in most of the code-related threads... I'm fully aware of the difference between a #define and a C++ constant. In C++ there is almost never a good reason to use a #define for a constant value (in C, "const" values can't be used at compile time (e.g. for array definitions) so they're a necessary evil there). There is at least one C++ style guide that advocates capitalising constants and it also makes sense if you have C and C++ mixed in a project (especially if the same name is used for a #define or a "const" depending on whether __cplusplus is defined...).

And no, replacing those C-style casts with "reinterpret_cast" won't make any warnings appear, although the syntax would possibly make it harder to accidentally omit a variable name at the expense of general readability.

The outer cast - sure, but the inner cast should be a static_cast and that doesn't allow you to cast an address to an int.

And for the capitalization - well, do whatever you want, but this way you easily lose track of what is a preprocessor macro and what isn't, and that's definitely not good.

something goes wrong

max wrote:something goes wrong

It looks like an underwater tunnel with a submarine inside.

This bug:



I don't know how it's physically possible. How can list->elements be NULL when ptr is not? They are the same type, and there's no way any code is executing in between because interrupts are disabled and the interrupt/exception handler prints a message when it executes.

I'm so confused.

It's impossible to answer that without seeing the definition of the struct list. Is it also a void**? Why is your memory allocater returning a void** rather than a void*? Are you sure that the line you have highlighted is the one printing the numbers? Why are you getting a kernel panic if the memory allocation didn't fail?

Questions, questions.

And the most important question - why haven't you single-stepped the code in a debugger, when the answer to your confusion should be obvious?

iansjack wrote:It's impossible to answer that without seeing the definition of the struct list. Is it also a void**?

I said they are the same type. They are both void**.

iansjack wrote:Why is your memory allocater returning a void** rather than a void*?

It is returning void*, hence the cast.

iansjack wrote:Are you sure that the line you have highlighted is the one printing the numbers?

Yes, no other code is printing those two numbers.

iansjack wrote:Why are you getting a kernel panic if the memory allocation didn't fail?

Because list->elements is NULL. Later on in the function, you will see "if list->elements == NULL return NULL". The function calling this function is create_heap and if place_sorted_list returns NULL it generates the kernel panic.

I know the memory allocation didn't actually fail but for some reason the assignment to list->elements fails and I am debugging it.

iansjack wrote:And the most important question - why haven't you single-stepped the code in a debugger, when the answer to your confusion should be obvious?

I did, and I couldn't figure it out. I can't do it now because I'm unexpectedly away from my computer for a week.

I guess this bug does not occur when optimizations are disabled right?