Trying to understand the Angband 3.X source code

[ekolis]

-1 == 255? Maybe in byte-land, but what if you're using multi-byte character sets (Unicode)?

[d_m]

In C, -1 has a two's complement binary representation as "1111111...." for whatever size integer you're talking about. If you cast it to (char) like Pete did, you end up with "11111111" in binary, which is 0xFF in hex, and 255 in decimal.

I think you're confused... in C the char datatype is always defined as one byte. If you want to represent a unicode character you'd use a different type. (char)-1 == (char)255 is invariant.

[nppangband]

What compiler are you using that complains about '\xff'? That is bog standard (char)-1
encoding.
Anyway, you are right, making it a #define constant is the right thing to do in any case.

LCC-Win 32, but I don't think that is the problem. The most current NPP is based on Angband 3.0.6, and I am dropping in Angband code from the latest release. With the re-writing of all the main.xxx files, the list of things that are #defined or #undef are completely different. I believe I am missing a #defined or there is an extra #undef that needs deleting. The fact that I am getting a compiler warning that bool is defined twice tells me I need to have to check this, file by file.

Does anyone have any recomendations for a good, free C compiler if LCC-WIN is the problem? My biggest limitation is that I am not a true programmer who could work off of a C:\ prompt. It would have to be a windows environment.....

[ekolis]

If you use mingw/msys, you can just use the makefiles out of the box as if you were in Linux... if you're looking for an actual IDE, there's Visual C++ Express; I successfully got angband to compile in it after a bit of finagling, and I can send you the project files necessary if you'd like!

[Pete Mack]

@jeff--
just about everyone uses gcc (MINGW on Windows) for compiling angband, though lcc is supposed to work too. I agree that redefines of bool are a much worse sign. (And why there's a #define for bool in the first place is beyond me. It's a standard data type in C99 and later.)

[d_m]

@jeff--
(And why there's a #define for bool in the first place is beyond me. It's a standard data type in C99 and later.)

Current Angband coding guidelines target C89, so C99's bool is not available.

It's worth asking Takk about this, I think.

[nppangband]

Current Angband coding guidelines target C89, so C99's bool is not available.

It's worth asking Takk about this, I think.

Line 155 of h-basic.h has this:

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

Then a couple lines later, there is this:

/*
* 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;

and around line 50 of the same file, there is this....about STDBOOL...

/*
* Using C99, assume we have stdint and stdbool
*/
# if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L
# define HAVE_STDINT_H
# define HAVE_STDBOOL_H
# endif

and at that point my little brain explodes..... I have no clue what is going on there. I assume it is an attempt to standardize the definition of bool for certain operating systems and compilers. But I doubt I could even understand it if somebody tried to explain it to me.

[nppangband]

OK, gonig back to basics, what files are needed to compile Angband version 3.1.2 v2 on windows. If I get that going with LCC_win32, I can see what warnings come up.

I assume:

angband.rc

in the src directory:
the files attack.c through load.c. Is load-old.c needed?
main-win.c
files option.c through z-virt.c

now, for the src/subdirectories:
doc - nothing?
gtk - nothing?
lcc - nothing?
monster - melee1, melee2, monster1, monster 2
nds - nothing?
object - identify.c through randart.c
osx - nothing
player - calcs.c, timed.c, and util.c (note here LCC_win fails becaule util.c has the same name as hte file in the src directory. All files have to have different names regardless of which directory they are in)
tests - nothing? There are three files, smaple.c, z-file.c, and z-tets.c. Are these experimental, or should they be included?
win - readdib.c

I would experiment with this, but the feature to delete a *.c file from a makefile in LCC_win is broken. I can add them, but if I need to delete a file I have to start all over.

[Pete Mack]

Current Angband coding guidelines target C89, so C99's bool is not available.

It's worth asking Takk about this, I think.

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

[nppangband]

'\xff' is (or should be) a character constant, kind of like '\n' or '\011'. In this case it's the number 255, aka 0377 in octal notation, aka 0xFF in hex notation.

I understand the problem now. It isn't the constant, but the fact that the Angband code places that code into a signed char variable. It was warning me that I was putting a value of 255 into a variable with a range of -127 to 128. When I changed the varible key in the structure ui_event_data (ui-event.h) to an unsigned character my compiler stopped complaining. Is that variable intended to hold values from -127 to -1?

[nppangband]

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]

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]

"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]

"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.