Page 1 of 1

large integer implicitly truncated to unsigned type

Posted: Thu Jan 12, 2017 2:39 am
by DixiumOS
I am trying to follow Bran's IDT tutorial (changing some things, of course).

However, i get a overflow error (trying to fit a value that is larger than possible).
How would i fix this overflow error?

Current code as of now is at DixiumOS-1 repo here.
Problem is located at interrupts/idt.c, function idt_install, at line

Code: Select all

idtp.limit = (sizeof (struct idt_entry) * 256) - 1;
"warning: large integer implicitly truncated to unsigned type [-Woverflow]"

Re: large integer implicitly truncated to unsigned type

Posted: Thu Jan 12, 2017 2:45 am
by Octocontrabass
What is the value you are trying to assign to idtp.limit?

What is the type of idtp.limit?

What is the range of possible values for that type?

Re: large integer implicitly truncated to unsigned type

Posted: Thu Jan 12, 2017 5:31 am
by dozniak
How did you manage to copypaste the code with mistakes?

I'm not really amazed, just tired by the SNR.

Re: large integer implicitly truncated to unsigned type

Posted: Thu Jan 12, 2017 5:36 am
by DixiumOS
dozniak wrote:How did you manage to copypaste the code with mistakes?

I'm not really amazed, just tired by the SNR.
Oops. Silly me.
That fixed the problem, thank you. :P

I need to fix my IDT code though. It triple faults the system for whatever reason.

Re: large integer implicitly truncated to unsigned type

Posted: Thu Jan 12, 2017 5:51 am
by iansjack
DixiumOS wrote: I need to fix my IDT code though. It triple faults the system for whatever reason.
'Twas ever thus.

So, fix it. Don't keep listing all of your mistakes; it just confirms people's opinion.

Re: large integer implicitly truncated to unsigned type

Posted: Thu Jan 12, 2017 5:53 am
by Octocontrabass
DixiumOS wrote:It triple faults the system for whatever reason.
Your function to install the ISRs calls the ISRs and places their return value to the IDT instead of placing the function pointer in the IDT.

But it never gets that far, because the first ISR it calls has IRET in inline assembly, which tries to use the stack frame as a return address.