Trying to understand the Angband 3.X source code

[nppangband]

Originally Posted by Pete Mack

Yep. There is no reason to code to a 20 year old standard when a 10 year old standard is available.

In looking at h-basic.h, line 157 of the code is redundant:

155 * C++ defines its own bool type, so we hack around it */
156 #undef bool
157 #define bool bool_hack

a coule lines later, bool is re-defined anyway, either through stdbool.h, or it is defined as a char for the systems that don't have STDBOOH_H...

/*
* Use a real bool type where possible
*/
#ifdef HAVE_STDBOOL_H

#include <stdbool.h>

#define TRUE true
#define FALSE false

#else

/* Use a char otherwise */
typedef char bool;

#undef TRUE
#undef FALSE

#define TRUE 1
#define FALSE 0

[takkaria]

Originally Posted by nppangband

In looking at h-basic.h, line 157 of the code is redundant:

155 * C++ defines its own bool type, so we hack around it */
156 #undef bool
157 #define bool bool_hack

a coule lines later, bool is re-defined anyway, either through stdbool.h, or it is defined as a char for the systems that don't have STDBOOH_H...

"bool" doesn't get redefined-- the #define bool bool_hack means that "bool_hack" is defined later, and everywhere in Angband that uses "bool" is actually using "bool_hack". I believe this is to work around people trying to use C++ compilers with Angband that define their own bool types.

[nppangband]

Originally Posted by takkaria

"bool" doesn't get redefined-- the #define bool bool_hack means that "bool_hack" is defined later, and everywhere in Angband that uses "bool" is actually using "bool_hack". I believe this is to work around people trying to use C++ compilers with Angband that define their own bool types.

You are right. I know you & the the vanilla dev team know much more about this than I do. I can make the Angband source do what I want, but that is the limit of my programming knowledge.

That line gave me half of a page of compiler errors. "bool_hack" doesn't seem to be defined or exist anywhere else in the angband source. Actually, according to google, it doesn't exist anywhere else in the world either. So I removed it and all the compiler errors went away. Am I missing something & do I need bool_hack defined?

Am I reading that other code correctly? It looks like the line before undefines bool, and a couple lines later, if HAVE_STDBOOL_H, bool is defined by stdbool.h, and if I don't, it is defined as a bool. So why would bool_hack need to be defined?

Thanks.

[zaimoni]

Originally Posted by takkaria

"bool" doesn't get redefined-- the #define bool bool_hack means that "bool_hack" is defined later, and everywhere in Angband that uses "bool" is actually using "bool_hack". I believe this is to work around people trying to use C++ compilers with Angband that define their own bool types.

A correct workaround is
1) ditch the #define (which invokes undefined behavior all versions of C++)
2) only bother with typedef'ing bool in C
3) Keep the rest of the code.

[Pete Mack]

A better workaround is to ditch all the stuff around bool, and change the compiler option -c89... to -c99

Then do a global replace TRUE by true and FALSE by false.
The messing around with non-standard boolean types is a highly undesirable archaism.

[zaimoni]

Requiring C99 means dropping support for both MSVC (C89 compiler only) and native MingW32 (recent standard header releases don't compile as C99).

[Pete Mack]

MSVC doesn't support full c99, but it does support the intersection of c99 with C++.
So bool is ok, but it's a built-in. (Dont' include stdbool.h)

[nppangband]

I have a bug that should be simple to fix, but I don't know where to do it.

The game crashes if I use the up, down, left, or right direction keys on my keyboard without the numlock on, but the diagonal direction keys work fine. It crashes on this line, in textui_process_command.

assert(p_ptr->command_cmd >= CHAR_MIN && p_ptr->command_cmd <= CHAR_MAX);

If the numlock is on, the p_ptr->command is 59, and if numlock is off, the direction keys are between 138-141, and the game crashes. Again, the diagonal keys work fine either way

Isn't there a pref file that converts certain keyboard commands like this? I know the 138 is above the 127 limit, but I can't figure out why it would be crashing the game. I have assert.h declared in h-basic.h just like in Angband.

Any thoughts or suggestions? I am stumped. Thanks.

[Nick]

Originally Posted by nppangband

assert(p_ptr->command_cmd >= CHAR_MIN && p_ptr->command_cmd <= CHAR_MAX);

If the numlock is on, the p_ptr->command is 59, and if numlock is off, the direction keys are between 138-141, and the game crashes. Again, the diagonal keys work fine either way

Isn't there a pref file that converts certain keyboard commands like this? I know the 138 is above the 127 limit, but I can't figure out why it would be crashing the game. I have assert.h declared in h-basic.h just like in Angband.

The relevant file is pref-win.prf, IIRC. I have had endless troubles with it and arrow keys.
If I understand assert correctly, that is what it does - if the condition is not satisfied, it terminates the program.
Good luck

[nppangband]

Originally Posted by Nick

The relevant file is pref-win.prf, IIRC. I have had endless troubles with it and arrow keys.
If I understand assert correctly, that is what it does - if the condition is not satisfied, it terminates the program.
Good luck

Thanks! With that help I found it. Strangely, utting in the updated pref-win.prf fromthe current angband into NPP causes the crashes. If I keep the current one from NPPAngband it works fine.