When your OS goes crazy - Screenshots

[Griwes]

I'll never use -Werror for very simple reason: templates in C++.

Example: I've templated function to convert integers to strings (one of those mentioned here on osdev.org, but a bit modified and C++ed). Now, I do simple "if (i < 0) {...}", where i is of templated type... and I get a warning: "comparison of unsigned expression < 0 is always false [-Wtype-limits]". I would have to write distinct version of that function for "unsigned" types just to keep that warning away - which doesn't make much sense. Although -Wall -Wextra is definitely a "must have" for every C/C++ project (and probably many more of them).

[TreahBlade]

Funny thing is the warnings that were shown were NASM warnings not GCC. They are perfectly fine warnings about labels that don't have a : at the end of them so something like .loophere will produce a warning but .loophere: will not. Its a perfectly ok warning to ignore and is even encouraged to do so on the OSDEV wiki.

Also gcc is not perfect and can generate warnings that are sometimes bugs in the compiler or just code that is not 100% in spec but perfectly ok to compile. Only a few are actual bugs in gcc where it will throw a warning when its not supposed to and the others can be a problem later. Sometimes when GCC is updated its more strict on code and warnings can then become errors in later revisions and cause older code to no longer compile. This is a common problem with some older GNU code sometimes.

It is a good idea to always attempt to fix warnings but there are some that are not possible to fix and can be safely ignored. Its always a good idea to treat warnings as errors unless you are absolutely certain that the warning is something that can be safely ignored.

[NickJohnson]

I would agree with using -Werror -Wall -Wextra (et al.) with one exception: -Wunused-parameter. It throws a wrench in any proper attempt to use function pointers to simulate polymorphism in C.

[Kazinsal]

Funny thing is the warnings that were shown were NASM warnings not GCC. They are perfectly fine warnings about labels that don't have a : at the end of them so something like .loophere will produce a warning but .loophere: will not. Its a perfectly ok warning to ignore and is even encouraged to do so on the OSDEV wiki.

"Label alone on line without colon may be in error" means "hey, you have a typo, fix it". Not, "hey, you have a typo, but that's okay, it doesn't affect anything at this particular moment of time, so ignore it completely!"

Now, if you have a label called, say "do_a20_test" and you forgot to put a colon after it, then you later create a macro called "do_a20_test", you're going to have weird results that may include NASM erroring out any you going nuts trying to figure out why.

All because you ignored a warning.

[Griwes]

My LFB printing code failed again, this time when I tried to fix broken 16bit text printing; well, before I started, it looked a bit better than now

[TreahBlade]

Funny thing is the warnings that were shown were NASM warnings not GCC. They are perfectly fine warnings about labels that don't have a : at the end of them so something like .loophere will produce a warning but .loophere: will not. Its a perfectly ok warning to ignore and is even encouraged to do so on the OSDEV wiki.

"Label alone on line without colon may be in error" means "hey, you have a typo, fix it". Not, "hey, you have a typo, but that's okay, it doesn't affect anything at this particular moment of time, so ignore it completely!"

Now, if you have a label called, say "do_a20_test" and you forgot to put a colon after it, then you later create a macro called "do_a20_test", you're going to have weird results that may include NASM erroring out any you going nuts trying to figure out why.

All because you ignored a warning.

Indeed a very good argument for fixing them . I actually have since fixed all my labels as that was very dirty "just get it working" code.

[sounds]

I just reworked the console driver.

There's an off-screen buffer that gets blitted on-screen for scrolling. I think the console driver (or graphics driver) is one of the most fun areas of an OS to debug.

[sounds]

It's fixed now.

[cxzuk]

I'll never use -Werror for very simple reason: templates in C++.

Example: I've templated function to convert integers to strings (one of those mentioned here on osdev.org, but a bit modified and C++ed). Now, I do simple "if (i < 0) {...}", where i is of templated type... and I get a warning: "comparison of unsigned expression < 0 is always false [-Wtype-limits]". I would have to write distinct version of that function for "unsigned" types just to keep that warning away - which doesn't make much sense. Although -Wall -Wextra is definitely a "must have" for every C/C++ project (and probably many more of them).

Why template instead of Conversion Operators?

[cxzuk]

I would agree with using -Werror -Wall -Wextra (et al.) with one exception: -Wunused-parameter. It throws a wrench in any proper attempt to use function pointers to simulate polymorphism in C.

Do you have an example of what you mean?

[NickJohnson]

I would agree with using -Werror -Wall -Wextra (et al.) with one exception: -Wunused-parameter. It throws a wrench in any proper attempt to use function pointers to simulate polymorphism in C.

Do you have an example of what you mean?

Just any case in which you're registering callbacks for something, and the callback function signature has parameters that are not always used (but can't be removed because they're necessary in other cases.)

[Griwes]

I would agree with using -Werror -Wall -Wextra (et al.) with one exception: -Wunused-parameter. It throws a wrench in any proper attempt to use function pointers to simulate polymorphism in C.

Do you have an example of what you mean?

Just any case in which you're registering callbacks for something, and the callback function signature has parameters that are not always used (but can't be removed because they're necessary in other cases.)

You do know that when you leave unused parameter unnamed, it will not produce warning, don't you?

[iON]

AOS version build 99999 Million(ok so that's exaggerating but i did so many different things so far.)

does this mean Tait is welcome?

I tried to fix printing 2 random characters instead of a string, but that seems to made it WAY worse.

-------
joke:
if you look closely, you can make out the word "Tait".
so bochs, got something to tell me about your favorites?
lol.
-------

[GAT]

Don't know if this counts as crazy, but I'm testing out a hash function, and apparently it's to eleet to work.

[Khronos]

I had this error writing my Screen driver...

EDIT: Problem fixed, I forgot update the VGA base pointer

Code: Select all

void screen::kputs(const char * string)
{
	for (; *string != '\0'; string++)
	{
		if (*string == '\n')
			VGA_PTR += VGA_WIDTH - ((VGA_PTR - (WORD *)VGA_ADDRESS) % VGA_WIDTH);
		else
			*VGA_PTR++ = 0x0700 | *string;

		if (*(int*)(void*)&VGA_PTR >= VGA_MAX_ADDRESS) //Scroll!
		{
			asm(".intel_syntax noprefix");
			__asm__("push rcx\n"
					"push rax\n" //Push

					"lea rdi, [0xB8000]\n" //Line 0
					"lea rsi, [0xB80A0]\n" //Line 1
					"mov rcx, 1920\n"	//24 * 80

					"rep movsw\n" //Scroll up the 24 lines

					"lea rsi, [0xB8F00]\n" //Line 25
					"mov rcx, 79\n"
					"mov ax, 0x0720\n" //Attributes with ' '
					
					".scroll_loop:\n"
						"mov [rsi], ax\n"
						"add rsi, 2\n"
						"dec rcx\n"
						"or rcx, rcx\n"
						"jnz .scroll_loop\n"
					//Empty the line 25

					"pop rax\n" //Pop
					"pop rcx");
			asm(".att_syntax noprefix");

			VGA_PTR = (WORD*)0xB8F00; //<------------------------------
		}
	}
}