Does my keyboard.h work?

iansjack · **Posted:** Mon Nov 14, 2016 1:27 pm

Sigh.

glauxosdever · **Posted:** Mon Nov 14, 2016 1:38 pm

Hi,

You need to be more self-reliant.

It's ok to ask questions about OS design. Asking, for example, in which ways scheduling could be implemented makes your perspective about scheduling wider and will help you make an informed decision. Moreover, some interesting opinions may be heard, and to experience will be exchanged between OS developers.

On the other hand, asking about errors spit out by the compiler doesn't really seem like an interesting question. People will probably think you don't have the required knowledge, and therefore will not want to help, considering the fact that these errors are easy to fix if you know a bit of C (or if you don't know you can still search about them on the internet). Note however that you shouldn't try to learn a programming language by doing OS development.

Another thing to consider, whether you are ready for OS development. If you can't fix errors, even after you have been told how to fix (most of) them, I fear at least one of these statements are true:

You have comprehension issues (i.e. can't understand what does the compiler say).
You are not ready for OS development (i.e. can't fix errors because of lacking knowledge).

Note however that these two issues are most likely interlinked, so it's most probable that both of them apply.

So before continuing, ask yourself whether you can deal with the complexity you will meet during OS development. It's not an easy journey, neither a hard one. It's very hard. So be prepared for it.

Regards,
glauxosdever

NunoLava1998 · **Joined:** Sun Oct 09, 2016 4:38 am **Posts:** 273

glauxosdever wrote:

Hi,

You need to be more self-reliant.

It's ok to ask questions about OS design. Asking, for example, in which ways scheduling could be implemented makes your perspective about scheduling wider and will help you make an informed decision. Moreover, some interesting opinions may be heard, and to experience will be exchanged between OS developers.

On the other hand, asking about errors spit out by the compiler doesn't really seem like an interesting question. People will probably think you don't have the required knowledge, and therefore will not want to help, considering the fact that these errors are easy to fix if you know a bit of C (or if you don't know you can still search about them on the internet). Note however that you shouldn't try to learn a programming language by doing OS development.

Another thing to consider, whether you are ready for OS development. If you can't fix errors, even after you have been told how to fix (most of) them, I fear at least one of these statements are true:

You have comprehension issues (i.e. can't understand what does the compiler say).
You are not ready for OS development (i.e. can't fix errors because of lacking knowledge).

Note however that these two issues are most likely interlinked, so it's most probable that both of them apply.

So before continuing, ask yourself whether you can deal with the complexity you will meet during OS development. It's not an easy journey, neither a hard one. It's very hard. So be prepared for it.

Regards,
glauxosdever

[*] Mostly the case. warning: things that should belong in sewageoverflow sucks ahead I find solutions for some experienced people which don't really have a "solution" SewageOverflow -.-, so i don't seem to "learn" as SewageOverflow promises.
[*] Kinda, but i am training. It took me a while before i realized i was dumb for trying to write a pixel in text mode.

Kevin · **Posted:** Mon Nov 14, 2016 3:18 pm

You either lack basic programming skills or at least pretend so. In either case, this isn't the right forum for you because your problem isn't related to OS development at all.

iansjack · **Posted:** Mon Nov 14, 2016 4:44 pm

Hey, they were only silly warnings, not errors, so they can just be ignored. I mean, applying strlen() to an integer is going to give a result. What could possibly go wrong?

Schol-R-LEA · **Posted:** Mon Nov 14, 2016 5:06 pm

Lukand wrote:

Enums are evil, instead use #define .

Thats an odd statement to make. Mind explaining your reasoning here? I agree that this isn't a good use for them (honestly, I would have gone with a few bitwise tests followed by a lookup table over either of those approaches), but in general I would consider enumerations them useful.

Schol-R-LEA · **Posted:** Mon Nov 14, 2016 10:06 pm

Just to help make it clear, here are two links that might help - assuming you are willing to, you know, learn from them:

Wiki: PS/2 Keyboard - the wiki docs on the standard model PC keyboard (while both the old IBM PC 0.75cm DIN connector is now ancient history, and the PS/2 connector has been almost entirely supplanted by the USB, the programming interface is largely unchanged since the PC/AT of 1985.)

Brendan's extended recommendations on writing a finite-state machine for scan code recognition (the first link on each entry is the start of the thread, the following links are his answers).

Keyboard Input: #1 and #2
Multi-Byte Keyboard Scancodes: #1
Properly written keyboard driver: #1, #2, #3, and #4
not unique keyboard scancodes: #1,#2,#3,#4,and #5

At the very least, read the wiki page and the first two sets of replies, and use them to write the code yourself. You will not be able to Frankenstein this part, or most of the other parts that still lie ahead, so get good.

Ycep · **Joined:** Mon Dec 28, 2015 11:11 am **Posts:** 401

Schol-R-LEA wrote:

Lukand wrote:

Enums are evil, instead use #define .

Thats an odd statement to make. Mind explaining your reasoning here? I agree that this isn't a good use for them (honestly, I would have gone with a few bitwise tests followed by a lookup table over either of those approaches), but in general I would consider enumerations them useful.

Since enums do not support any type except signed integer (except in C++ 2011), you have to cast them to convert them to anything not their type, compiler portability, etc.
#define's look better and they do not get compiled.

Ycep · **Joined:** Mon Dec 28, 2015 11:11 am **Posts:** 401

Your new code is so better than your first one. Good improvement.
Your current problem is ... Goddamit, why do you use pointer to pointer of int for Key!?
To be compilant with my license, Nuno (whatever his surname is) has my premission to redistribute file "keyb.cpp" and function getch() located in "richio.cpp".
https://github.com/lukaandjelkovic/Nutoak
Just change it to be compatible with your operating system.

Schol-R-LEA · **Posted:** Tue Nov 15, 2016 6:25 pm

Lukand wrote:

Schol-R-LEA wrote:

Lukand wrote:

Enums are evil, instead use #define .

Thats an odd statement to make. Mind explaining your reasoning here? I agree that this isn't a good use for them (honestly, I would have gone with a few bitwise tests followed by a lookup table over either of those approaches), but in general I would consider enumerations them useful.

Since enums do not support any type except signed integer (except in C++ 2011), you have to cast them to convert them to anything not their type, compiler portability, etc.
#define's look better and they do not get compiled.

Well... here's the thing. Enumerations aren't really meant to hold values at all, at least not in their original conception; they were for creating ranges of values where the values themselves weren't significant, only the order. The idea was to have an easy way to define a range type that could hold things like days of the week and so forth - something that could be used in an if() or switch() but which would be otherwise valueless. You were never meant to use them for their values at all, just for the ordering they defined.

They are, in other words, for enumerating with, not for holding usable values.

The reason that assigning values to them came up at all was because some sequences were disjoint, that is, there were points where you had to have a gap in the values, because there was some significance to them but not as much as the ordering had. For cases like this, you would normally set a starting point at the beginning of the gap (or for the first element of the ordering) and let it auto-define the remainder:

Code:

typedef enum { JAN = 1, MAR = 3, MAY = 5, JUL = 7, AUG, OCT = 10, DEC = 12} Months_With_Thirty_One_Days;

This is something of a misuse of enums (one I have used myself in the past), one that is fairly common but not really entirely legit.

What Nuno did was to use them to group a set of constants without a specific ordering, which is the real problem I saw. Yes, they were related constants, but their ordering wasn't particularly crucial to how they were related, and worse, he explicitly defined all of them without regard to what ordering they did have. That's syntactically legal, but semantically meaningless.

osdever · **Joined:** Fri Apr 03, 2015 9:41 am **Posts:** 492

NunoLava1998 wrote:

glauxosdever wrote:

Yes.
I first set up a enum for easier reading and to not make this take more time.
I then set up a scan code get (inb/outb IS imported) and a key get which displays the pressed key as long it is in the list.
Here are the full list of errors/warnings/notes:

Code:

terminalf/fkbd.h:44:2: error: invalid suffix "P_SCD" on integer constant
  1P_SCD = 0x02,
  ^
terminalf/fkbd.h:44:2: error: expected identifier before numeric constant
terminalf/fkbd.h:45:2: error: invalid suffix "P_SCD" on integer constant
  2P_SCD = 0x03,
  ^
terminalf/fkbd.h:46:2: error: invalid suffix "P_SCD" on integer constant
  3P_SCD = 0x04,
  ^
terminalf/fkbd.h:47:2: error: invalid suffix "P_SCD" on integer constant
  4P_SCD = 0x05,
  ^
terminalf/fkbd.h:48:2: error: invalid suffix "P_SCD" on integer constant
  5P_SCD = 0x06,
  ^
terminalf/fkbd.h:49:2: error: invalid suffix "P_SCD" on integer constant
  6P_SCD = 0x07,
  ^
terminalf/fkbd.h:50:2: error: invalid suffix "P_SCD" on integer constant
  7P_SCD = 0x08,
  ^
terminalf/fkbd.h:51:2: error: invalid suffix "P_SCD" on integer constant
  8P_SCD = 0x09,
  ^
terminalf/fkbd.h:52:2: error: invalid suffix "P_SCD" on integer constant
  9P_SCD = 0x0A,
  ^
terminalf/fkbd.h:53:2: error: invalid suffix "P_SCD" on integer constant
  0P_SCD = 0x0B,
  ^
terminalf/fkbd.h: In function 'getchar':
terminalf/fkbd.h:73:8: error: 'scancode' undeclared (first use in this function)
 return scancode[getScancode()+1];
        ^
terminalf/fkbd.h:73:8: note: each undeclared identifier is reported only once for each function it appears in
terminalf/fkbd.h: In function 'getKey':
terminalf/fkbd.h:79:6: error: 'scancode' undeclared (first use in this function)
  if (scancode == AP_SCD)
      ^
terminalf/fkbd.h:190:16: warning: operation on 'terminal_row' may be undefined [-Wsequence-point]
   terminal_row = terminal_row++;
                ^
terminalf/fkbd.h:195:18: error: invalid suffix "P_SCD" on integer constant
  if (scancode == 1P_SCD)
                  ^
terminalf/fkbd.h:200:18: error: invalid suffix "P_SCD" on integer constant
  if (scancode == 2P_SCD)
                  ^
terminalf/fkbd.h:205:18: error: invalid suffix "P_SCD" on integer constant
  if (scancode == 3P_SCD)
                  ^
terminalf/fkbd.h:210:18: error: invalid suffix "P_SCD" on integer constant
  if (scancode == 4P_SCD)
                  ^
terminalf/fkbd.h:215:18: error: invalid suffix "P_SCD" on integer constant
  if (scancode == 5P_SCD)
                  ^
terminalf/fkbd.h:220:18: error: invalid suffix "P_SCD" on integer constant
  if (scancode == 6P_SCD)
                  ^
terminalf/fkbd.h:225:18: error: invalid suffix "P_SCD" on integer constant
  if (scancode == 7P_SCD)
                  ^
terminalf/fkbd.h:230:18: error: invalid suffix "P_SCD" on integer constant
  if (scancode == 8P_SCD)
                  ^
terminalf/fkbd.h:235:18: error: invalid suffix "P_SCD" on integer constant
  if (scancode == 9P_SCD)
                  ^
terminalf/fkbd.h:240:18: error: invalid suffix "P_SCD" on integer constant
  if (scancode == 0P_SCD)
                  ^
terminalf/fkbd.h:245:18: error: 'SLASHP_SCD' undeclared (first use in this function)
  if (scancode == SLASHP_SCD)
                  ^
terminalf/fkbd.h:250:18: error: 'POINTP_SCD' undeclared (first use in this function)
  if (scancode == POINTP_SCD)
                  ^
terminalf/fkbd.h:255:18: error: 'SINGQUOTP_SCD' undeclared (first use in this function)
  if (scancode == SINGQUOTP_SCD)
                  ^
terminalf/fkbd.h:260:18: error: 'EQUALP_SCD' undeclared (first use in this function)
  if (scancode == EQUALP_SCD)
                  ^
In file included from terminalf/f.c:7:0,
                 from kernel.c:8:
terminalf/printservices.h: At top level:
terminalf/printservices.h:20:6: error: nested redefinition of 'enum vga_color'
 enum vga_color {
      ^
terminalf/printservices.h:20:6: error: redeclaration of 'enum vga_color'
In file included from terminalf/fkbd.h:6:0,
                 from terminalf/f.c:6,
                 from kernel.c:8:
terminalf/printservices.h:20:6: note: originally defined here
 enum vga_color {
      ^
In file included from terminalf/f.c:7:0,
                 from kernel.c:8:
terminalf/printservices.h:21:2: error: redeclaration of enumerator 'VGA_COLOR_BLACK'
  VGA_COLOR_BLACK = 0,
  ^
In file included from terminalf/fkbd.h:6:0,
                 from terminalf/f.c:6,
                 from kernel.c:8:
terminalf/printservices.h:21:2: note: previous definition of 'VGA_COLOR_BLACK' was here
  VGA_COLOR_BLACK = 0,
  ^
In file included from terminalf/f.c:7:0,
                 from kernel.c:8:
terminalf/printservices.h:22:2: error: redeclaration of enumerator 'VGA_COLOR_BLUE'
  VGA_COLOR_BLUE = 1,
  ^
In file included from terminalf/fkbd.h:6:0,
                 from terminalf/f.c:6,
                 from kernel.c:8:
terminalf/printservices.h:22:2: note: previous definition of 'VGA_COLOR_BLUE' was here
  VGA_COLOR_BLUE = 1,
  ^
In file included from terminalf/f.c:7:0,
                 from kernel.c:8:
terminalf/printservices.h:23:2: error: redeclaration of enumerator 'VGA_COLOR_GREEN'
  VGA_COLOR_GREEN = 2,
  ^
In file included from terminalf/fkbd.h:6:0,
                 from terminalf/f.c:6,
                 from kernel.c:8:
terminalf/printservices.h:23:2: note: previous definition of 'VGA_COLOR_GREEN' was here
  VGA_COLOR_GREEN = 2,
  ^
In file included from terminalf/f.c:7:0,
                 from kernel.c:8:
terminalf/printservices.h:24:2: error: redeclaration of enumerator 'VGA_COLOR_CYAN'
  VGA_COLOR_CYAN = 3,
  ^
In file included from terminalf/fkbd.h:6:0,
                 from terminalf/f.c:6,
                 from kernel.c:8:
terminalf/printservices.h:24:2: note: previous definition of 'VGA_COLOR_CYAN' was here
  VGA_COLOR_CYAN = 3,
  ^
In file included from terminalf/f.c:7:0,
                 from kernel.c:8:
terminalf/printservices.h:25:2: error: redeclaration of enumerator 'VGA_COLOR_RED'
  VGA_COLOR_RED = 4,
  ^
In file included from terminalf/fkbd.h:6:0,
                 from terminalf/f.c:6,
                 from kernel.c:8:
terminalf/printservices.h:25:2: note: previous definition of 'VGA_COLOR_RED' was here
  VGA_COLOR_RED = 4,
  ^
In file included from terminalf/f.c:7:0,
                 from kernel.c:8:
terminalf/printservices.h:26:2: error: redeclaration of enumerator 'VGA_COLOR_MAGENTA'
  VGA_COLOR_MAGENTA = 5,
  ^
In file included from terminalf/fkbd.h:6:0,
                 from terminalf/f.c:6,
                 from kernel.c:8:
terminalf/printservices.h:26:2: note: previous definition of 'VGA_COLOR_MAGENTA' was here
  VGA_COLOR_MAGENTA = 5,
  ^
In file included from terminalf/f.c:7:0,
                 from kernel.c:8:
terminalf/printservices.h:27:2: error: redeclaration of enumerator 'VGA_COLOR_BROWN'
  VGA_COLOR_BROWN = 6,
  ^
In file included from terminalf/fkbd.h:6:0,
                 from terminalf/f.c:6,
                 from kernel.c:8:
terminalf/printservices.h:27:2: note: previous definition of 'VGA_COLOR_BROWN' was here
  VGA_COLOR_BROWN = 6,
  ^
In file included from terminalf/f.c:7:0,
                 from kernel.c:8:
terminalf/printservices.h:28:2: error: redeclaration of enumerator 'VGA_COLOR_LIGHT_GREY'
  VGA_COLOR_LIGHT_GREY = 7,
  ^
In file included from terminalf/fkbd.h:6:0,
                 from terminalf/f.c:6,
                 from kernel.c:8:
terminalf/printservices.h:28:2: note: previous definition of 'VGA_COLOR_LIGHT_GREY' was here
  VGA_COLOR_LIGHT_GREY = 7,
  ^
In file included from terminalf/f.c:7:0,
                 from kernel.c:8:
terminalf/printservices.h:29:2: error: redeclaration of enumerator 'VGA_COLOR_DARK_GREY'
  VGA_COLOR_DARK_GREY = 8,
  ^
In file included from terminalf/fkbd.h:6:0,
                 from terminalf/f.c:6,
                 from kernel.c:8:
terminalf/printservices.h:29:2: note: previous definition of 'VGA_COLOR_DARK_GREY' was here
  VGA_COLOR_DARK_GREY = 8,
  ^
In file included from terminalf/f.c:7:0,
                 from kernel.c:8:
terminalf/printservices.h:30:2: error: redeclaration of enumerator 'VGA_COLOR_LIGHT_BLUE'
  VGA_COLOR_LIGHT_BLUE = 9,
  ^
In file included from terminalf/fkbd.h:6:0,
                 from terminalf/f.c:6,
                 from kernel.c:8:
terminalf/printservices.h:30:2: note: previous definition of 'VGA_COLOR_LIGHT_BLUE' was here
  VGA_COLOR_LIGHT_BLUE = 9,
  ^
In file included from terminalf/f.c:7:0,
                 from kernel.c:8:
terminalf/printservices.h:31:2: error: redeclaration of enumerator 'VGA_COLOR_LIGHT_GREEN'
  VGA_COLOR_LIGHT_GREEN = 10,
  ^
In file included from terminalf/fkbd.h:6:0,
                 from terminalf/f.c:6,
                 from kernel.c:8:
terminalf/printservices.h:31:2: note: previous definition of 'VGA_COLOR_LIGHT_GREEN' was here
  VGA_COLOR_LIGHT_GREEN = 10,
  ^
In file included from terminalf/f.c:7:0,
                 from kernel.c:8:
terminalf/printservices.h:32:2: error: redeclaration of enumerator 'VGA_COLOR_LIGHT_CYAN'
  VGA_COLOR_LIGHT_CYAN = 11,
  ^
In file included from terminalf/fkbd.h:6:0,
                 from terminalf/f.c:6,
                 from kernel.c:8:
terminalf/printservices.h:32:2: note: previous definition of 'VGA_COLOR_LIGHT_CYAN' was here
  VGA_COLOR_LIGHT_CYAN = 11,
  ^
In file included from terminalf/f.c:7:0,
                 from kernel.c:8:
terminalf/printservices.h:33:2: error: redeclaration of enumerator 'VGA_COLOR_LIGHT_RED'
  VGA_COLOR_LIGHT_RED = 12,
  ^
In file included from terminalf/fkbd.h:6:0,
                 from terminalf/f.c:6,
                 from kernel.c:8:
terminalf/printservices.h:33:2: note: previous definition of 'VGA_COLOR_LIGHT_RED' was here
  VGA_COLOR_LIGHT_RED = 12,
  ^
In file included from terminalf/f.c:7:0,
                 from kernel.c:8:
terminalf/printservices.h:34:2: error: redeclaration of enumerator 'VGA_COLOR_LIGHT_MAGENTA'
  VGA_COLOR_LIGHT_MAGENTA = 13,
  ^
In file included from terminalf/fkbd.h:6:0,
                 from terminalf/f.c:6,
                 from kernel.c:8:
terminalf/printservices.h:34:2: note: previous definition of 'VGA_COLOR_LIGHT_MAGENTA' was here
  VGA_COLOR_LIGHT_MAGENTA = 13,
  ^
In file included from terminalf/f.c:7:0,
                 from kernel.c:8:
terminalf/printservices.h:35:2: error: redeclaration of enumerator 'VGA_COLOR_LIGHT_BROWN'
  VGA_COLOR_LIGHT_BROWN = 14,
  ^
In file included from terminalf/fkbd.h:6:0,
                 from terminalf/f.c:6,
                 from kernel.c:8:
terminalf/printservices.h:35:2: note: previous definition of 'VGA_COLOR_LIGHT_BROWN' was here
  VGA_COLOR_LIGHT_BROWN = 14,
  ^
In file included from terminalf/f.c:7:0,
                 from kernel.c:8:
terminalf/printservices.h:36:2: error: redeclaration of enumerator 'VGA_COLOR_WHITE'
  VGA_COLOR_WHITE = 15,
  ^
In file included from terminalf/fkbd.h:6:0,
                 from terminalf/f.c:6,
                 from kernel.c:8:
terminalf/printservices.h:36:2: note: previous definition of 'VGA_COLOR_WHITE' was here
  VGA_COLOR_WHITE = 15,
  ^
In file included from terminalf/f.c:7:0,
                 from kernel.c:8:
terminalf/printservices.h:39:23: error: redefinition of 'vga_entry_color'
 static inline uint8_t vga_entry_color(enum vga_color fg, enum vga_color bg) {
                       ^
In file included from terminalf/fkbd.h:6:0,
                 from terminalf/f.c:6,
                 from kernel.c:8:
terminalf/printservices.h:39:23: note: previous definition of 'vga_entry_color' was here
 static inline uint8_t vga_entry_color(enum vga_color fg, enum vga_color bg) {
                       ^
In file included from terminalf/f.c:7:0,
                 from kernel.c:8:
terminalf/printservices.h:43:24: error: redefinition of 'vga_entry'
 static inline uint16_t vga_entry(unsigned char uc, uint8_t color) {
                        ^
In file included from terminalf/fkbd.h:6:0,
                 from terminalf/f.c:6,
                 from kernel.c:8:
terminalf/printservices.h:43:24: note: previous definition of 'vga_entry' was here
 static inline uint16_t vga_entry(unsigned char uc, uint8_t color) {
                        ^
In file included from terminalf/f.c:7:0,
                 from kernel.c:8:
terminalf/printservices.h:47:8: error: redefinition of 'strlen'
 size_t strlen(const char* str) {
        ^
In file included from terminalf/fkbd.h:6:0,
                 from terminalf/f.c:6,
                 from kernel.c:8:
terminalf/printservices.h:47:8: note: previous definition of 'strlen' was here
 size_t strlen(const char* str) {
        ^
In file included from terminalf/f.c:7:0,
                 from kernel.c:8:
terminalf/printservices.h:54:21: error: redefinition of 'VGA_WIDTH'
 static const size_t VGA_WIDTH = 80;
                     ^
In file included from terminalf/fkbd.h:6:0,
                 from terminalf/f.c:6,
                 from kernel.c:8:
terminalf/printservices.h:54:21: note: previous definition of 'VGA_WIDTH' was here
 static const size_t VGA_WIDTH = 80;
                     ^
In file included from terminalf/f.c:7:0,
                 from kernel.c:8:
terminalf/printservices.h:55:21: error: redefinition of 'VGA_HEIGHT'
 static const size_t VGA_HEIGHT = 25;
                     ^
In file included from terminalf/fkbd.h:6:0,
                 from terminalf/f.c:6,
                 from kernel.c:8:
terminalf/printservices.h:55:21: note: previous definition of 'VGA_HEIGHT' was here
 static const size_t VGA_HEIGHT = 25;
                     ^
In file included from terminalf/f.c:7:0,
                 from kernel.c:8:
terminalf/printservices.h:62:6: error: redefinition of 'terminal_initialize'
 void terminal_initialize(void) {
      ^
In file included from terminalf/fkbd.h:6:0,
                 from terminalf/f.c:6,
                 from kernel.c:8:
terminalf/printservices.h:62:6: note: previous definition of 'terminal_initialize' was here
 void terminal_initialize(void) {
      ^
In file included from terminalf/f.c:7:0,
                 from kernel.c:8:
terminalf/printservices.h:75:6: error: redefinition of 'terminal_setcolor'
 void terminal_setcolor(uint8_t color) {
      ^
In file included from terminalf/fkbd.h:6:0,
                 from terminalf/f.c:6,
                 from kernel.c:8:
terminalf/printservices.h:75:6: note: previous definition of 'terminal_setcolor' was here
 void terminal_setcolor(uint8_t color) {
      ^
In file included from terminalf/f.c:7:0,
                 from kernel.c:8:
terminalf/printservices.h:79:6: error: redefinition of 'terminal_putentryat'
 void terminal_putentryat(char c, uint8_t color, size_t x, size_t y) {
      ^
In file included from terminalf/fkbd.h:6:0,
                 from terminalf/f.c:6,
                 from kernel.c:8:
terminalf/printservices.h:79:6: note: previous definition of 'terminal_putentryat' was here
 void terminal_putentryat(char c, uint8_t color, size_t x, size_t y) {
      ^
In file included from terminalf/f.c:7:0,
                 from kernel.c:8:
terminalf/printservices.h:84:6: error: redefinition of 'terminal_putchar'
 void terminal_putchar(char c) {
      ^
In file included from terminalf/fkbd.h:6:0,
                 from terminalf/f.c:6,
                 from kernel.c:8:
terminalf/printservices.h:84:6: note: previous definition of 'terminal_putchar' was here
 void terminal_putchar(char c) {
      ^
In file included from terminalf/f.c:7:0,
                 from kernel.c:8:
terminalf/printservices.h:93:6: error: redefinition of 'terminal_write'
 void terminal_write(const char* data, size_t size) {
      ^
In file included from terminalf/fkbd.h:6:0,
                 from terminalf/f.c:6,
                 from kernel.c:8:
terminalf/printservices.h:93:6: note: previous definition of 'terminal_write' was here
 void terminal_write(const char* data, size_t size) {
      ^
In file included from terminalf/f.c:7:0,
                 from kernel.c:8:
terminalf/printservices.h:98:6: error: redefinition of 'terminal_writestring'
 void terminal_writestring(const char* data) {
      ^
In file included from terminalf/fkbd.h:6:0,
                 from terminalf/f.c:6,
                 from kernel.c:8:
terminalf/printservices.h:98:6: note: previous definition of 'terminal_writestring' was here
 void terminal_writestring(const char* data) {
      ^
In file included from terminalf/f.c:6:0,
                 from kernel.c:8:
terminalf/fkbd.h: In function 'getchar':
terminalf/fkbd.h:74:1: warning: control reaches end of non-void function [-Wreturn-type]
 }
 ^
terminalf/fkbd.h: In function 'getKey':
terminalf/fkbd.h:265:1: warning: control reaches end of non-void function [-Wreturn-type]
 }
 ^

(the majority are warnings that don't even make sense)

Oh sh*t. Please leave this forum if you don't know C even basically. Your code is full of warnings, it's very long, it now even compiles. You're either a troll or a man who started OS development without basic C knowledge.

osdever · **Joined:** Fri Apr 03, 2015 9:41 am **Posts:** 492

iansjack wrote:

Just go away and learn C rather than polluting this forum with silly posts.

+1

Ycep · **Joined:** Mon Dec 28, 2015 11:11 am **Posts:** 401

It's because some people do not even know general programming or even little bit algorithmic programming which try to create their OS.

Althrough, considering his age, better idea for him may be to learn more general/algorithmic programming, and then go there.
Come back there when you learn:

Enums
Pointers
POSIX functions (So you could explore and learn some algorithms and make your OS little bit POSIX compilant)
General code optimizations and cyclomatic complexity
Filling algorithm
Path finding algorithm
That Osdev Wiki is not copy-paste tutorial(through, some other bros did not learned it)
Recursive functions
To understand sentences
To understand patents, licenses, legal rights, trademark and (do not read it if you are ever going to live in USA and serve in a jury) law nullification
Sorting algorithm(For now, let it be simple one)

Wow, you have a looong road...

alexfru · **Joined:** Tue Mar 04, 2014 5:27 am **Posts:** 1108

Lukand wrote:

Since enums do not support any type except signed integer (except in C++ 2011), you have to cast them to convert them to anything not their type, compiler portability, etc.
#define's look better and they do not get compiled.

There's no overhead in handling constants, whether they come from the source code as macro substitutions or enumerations. The compiler sees a constant in both cases and can handle it equally efficiently.

If you want constants of types other than int, you should probably consider switching from C to C++. In C++ constants of basic numeric types (defined as "const numeric-type name = value;" or even constexpr) are guaranteed to be as efficient as plain constants or enumerations, the compiler will not treat them as constant objects that need to be read from memory (unless you want to do just that, take the address of such a constant and pass it somewhere for future dereferencing).

Macros do not respect scope and may, if you're not very careful, expand where you don't want them to. So, you have to name them in a special recognizable way and undefine them if you only need them in a small block of code. Enumerations don't need to be undefined when you're done using them, their definition is gone with the scope, where they're defined, just like with variables or other types. Also you're more likely to get a warning from misused enumerations than from plain ints and macros. For example, there's a very common pattern in code that benefits from enumerations, a switch statement on an enumerated type. If you use the right warning settings in your compiler, it will tell you if you're missing some of the enumeration cases. It won't tell you that if you switch on an int with cases on #defined constants. There's another problem with #defined constants. For example, 32768, what type is it? How about 0x8000? It depends on how types are defined in your compiler. OTOH, enums by default fit into signed ints and if an enumeration constant doesn't fit into a signed int you should get a compilation error. With #defined constants your code may compile and not work. For that reason there are special types and macros in <stdint.h>, e.g. uint16_t and UINT16_C(), which help get around the issues with types of constants. Unfortunately, <stdint.h> isn't perfect because it can't fix some of the problems inherent in the language itself (type conversions).

osdever · **Joined:** Fri Apr 03, 2015 9:41 am **Posts:** 492

Lukand wrote:

It's because some people do not even know general programming or even little bit algorithmic programming which try to create their OS.

Althrough, considering his age, better idea for him may be to learn more general/algorithmic programming, and then go there.
Come back there when you learn:

Enums
Pointers
POSIX functions (So you could explore and learn some algorithms and make your OS little bit POSIX compilant)
General code optimizations and cyclomatic complexity
Filling algorithm
Path finding algorithm
That Osdev Wiki is not copy-paste tutorial(through, some other bros did not learned it)
Recursive functions
To understand sentences
To understand patents, licenses, legal rights, trademark and (do not read it if you are ever going to live in USA and serve in a jury) law nullification
Sorting algorithm(For now, let it be simple one)

Wow, you have a looong road...

I agree. Nuno, sorry, but you need to learn that before writing an OS.

OSDev.org

Does my keyboard.h work?

Who is online