r1353 compile errors

[PaulBlay]

object/identify.c(166) : error C2275: 'u32b' : illegal use of this type as an ex
pression
c:\rl\angband311\src\h-basic.h(223) : see declaration of 'u32b'
object/identify.c(166) : error C2146: syntax error : missing ';' before identifier 'curses'
object/identify.c(166) : error C2065: 'curses' : undeclared identifier
object/identify.c(169) : error C2065: 'curses' : undeclared identifier
object/identify.c(173) : error C2065: 'curses' : undeclared identifier

You need to change object_notice_curses as follows.

bool object_notice_curses(object_type *o_ptr)
{
        u32b f[OBJ_FLAG_N];
        [b]u32b curses;[/b]
        object_flags(o_ptr, f);
        [b]curses = (f[2] & TR2_CURSE_MASK);[/b]
        
        /* Know whatever curse flags there are to know */
        o_ptr->known_flags[2] |= curses;

        p_ptr->notice |= PN_SQUELCH;

        return (curses ? TRUE : FALSE);
}

[Pete Mack]

Surely, surely, we can move to C99 by now, after a whole decade? The only file that enforces c90 is Makefile.win. Everything else assumes the default. (Which is C99 for most compilers...)

I even checked Open Watcom, and it has support for mixed code and declaration in partial c99 compliance, using -za99 compiler flag.

[PaulBlay]

I also get the following error when using VC++ Command Prompt with Makefile.nmake.

debug.o : warning LNK4217: locally defined symbol __iob imported in function _to_stderr
z-util.o : warning LNK4049: locally defined symbol __iob imported
cave.o : error LNK2019: unresolved external symbol __alloca referenced in function _display_map
score.o : error LNK2001: unresolved external symbol __alloca
Angband.exe : fatal error LNK1120: 1 unresolved externals

[PaulBlay]

The only file that enforces c90 is Makefile.win.

And Makefile.nmake apparently.

In r1354

void object_notice_flag(int flagset, u32b flag)
{
        int i;

        for (i = INVEN_WIELD; i < INVEN_TOTAL; i++)
        {
                object_type *o_ptr = &inventory[i];
                u32b f[OBJ_FLAG_N];

                object_flags(o_ptr, f);
                if ((f[flagset] & flag) &&
                                !(o_ptr->known_flags[flagset] & flag))
                {
                        char o_name[80];
                        object_desc(o_name, sizeof(o_name), o_ptr, FALSE,
                                        ODESC_BASE);

                        /* Notice flags */
                        o_ptr->known_flags[flagset] |= flag;

                        for ([B][COLOR="Red"]size_t [/COLOR][/B]j = 0; j < N_ELEMENTS(msgs); j++)
                        {
                                if (msgs[j].flagset == flagset &&
                                                (msgs[j].flag & flag))
                                        msg_format(msgs[j].msg, o_name);
                        }
                }
        }       

        return;
}

[Magnate]

Surely, surely, we can move to C99 by now, after a whole decade? The only file that enforces c90 is Makefile.win. Everything else assumes the default. (Which is C99 for most compilers...)

I'm no expert, but there are a lot of commits to trunk which are tidying-up to preserve C89 compatibility, so it looks quite important.

[takkaria]

I also get the following error when using VC++ Command Prompt with Makefile.nmake.

debug.o : warning LNK4217: locally defined symbol __iob imported in function _to_stderr
z-util.o : warning LNK4049: locally defined symbol __iob imported
cave.o : error LNK2019: unresolved external symbol __alloca referenced in function _display_map
score.o : error LNK2001: unresolved external symbol __alloca
Angband.exe : fatal error LNK1120: 1 unresolved externals

Try doing a clean make and going again? (The C89 things should be fixed now.)

[PaulBlay]

Try doing a clean make and going again? (The C89 things should be fixed now.)

It was OK at r1357 (I cleared out all the old *.o files just in case).

I suppose I should have tried one without doing that to see if it was any different, but too late now.

[Pete Mack]

alloca is not used in angband--it's highly non-portable. Did you change compile options?

[PaulBlay]

alloca is not used in angband--it's highly non-portable. Did you change compile options?

No, I used the same makefile both times.

[Pete Mack]

Are you absolutely sure all the .o files--including those in subdirectories--are compiled with the same compiler? Those errors look suspiciously like mismatched libraries, aka DLL Hell.

[PaulBlay]

Are you absolutely sure all the .o files--including those in subdirectories--are compiled with the same compiler? Those errors look suspiciously like mismatched libraries, aka DLL Hell.

Not 100% sure, but there's no way to check now.