Down to a single compiler warning.

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • PaulBlay
    Knight
    • Jan 2009
    • 657

    Down to a single compiler warning.

    Down to a single compiler warning, with VC++ at /W4 when compiling Angband/65. It's a pity that there are some real, game-crashing bugs, but hey! Only one compiler warning

    Anyway, that warning is

    warning C4550: expression evaluates to a function which is missing an argument list

    for
    Code:
    		keypress_h = askfor_aux_keypress;
    Exactly the same warning is given when compiling Vanilla Angband (along with 1306 other warnings). I haven't the foggiest idea what could, or should, be done to placate Visual Studio in that case (I tried stuff earlier, and made 'bad things' happen )
    Currently turning (Angband) Japanese.
  • Atarlost
    Swordsman
    • Apr 2007
    • 441

    #2
    Does it show in other compilers? It may just be that the people who wrote VCC think you shouldn't be trusted with function pointers.
    One Ring to rule them all. One Ring to bind them.
    One Ring to bring them all and in the darkness interrupt the movie.

    Comment

    • PaulBlay
      Knight
      • Jan 2009
      • 657

      #3
      Originally posted by Atarlost
      Does it show in other compilers?
      It doesn't on whatever-the-heck gets used in Linux (gcc, I guess).

      Originally posted by Atarlost
      It may just be that the people who wrote VCC think you shouldn't be trusted with function pointers.
      Well, maybe, but there are plenty of other superficially similar appearing lines which aren't complained about by VCC.

      Code:
      ang_sort_comp = ang_sort_comp_hook_longs;
      for instance.

      I can only assume it may have something to do with the weird looking way keypress_h is declared (in the middle of declaring askfor_aux).

      Code:
      extern bool askfor_aux(char *buf, size_t len, bool keypress_h(char *, size_t, size_t *, size_t *, char, bool));
      Currently turning (Angband) Japanese.

      Comment

      • PaulBlay
        Knight
        • Jan 2009
        • 657

        #4
        Originally posted by Atarlost
        It may just be that the people who wrote VCC think you shouldn't be trusted with function pointers.
        Alternative punchline:

        Hey, I don't think I should be trusted with function pointers.
        Currently turning (Angband) Japanese.

        Comment

        • LanceDiamond
          Rookie
          • Apr 2009
          • 13

          #5
          If you change it to:


          Code:
          (bool *) keypress_h = (bool *) askfor_aux_keypress;
          I think you'll shut VC up and it shouldn't hurt anything. I think VC is trying to tell you it's not sure if you're trying to call the function or trying to assign the pointer value.

          Comment

          • PaulBlay
            Knight
            • Jan 2009
            • 657

            #6
            Originally posted by LanceDiamond
            I think you'll shut VC up and it shouldn't hurt anything. I think VC is trying to tell you it's not sure if you're trying to call the function or trying to assign the pointer value.
            Well the good news is that it got rid of the original warning. The bad news is that it produced three more warnings it its place.

            Code:
            warning C4054: 'type cast' : from function pointer 'bool_hack (__cdecl *)(char *,size_t,size_t *,size_t *,char,bool_hack)' to data pointer 'bool_hack *'
            warning C4054: 'type cast' : from function pointer 'bool_hack (__cdecl *)(char *,size_t,size_t *,size_t *,char,bool_hack)' to data pointer 'bool_hack *'
            warning C4213: nonstandard extension used : cast on l-value
            Currently turning (Angband) Japanese.

            Comment

            • Atarlost
              Swordsman
              • Apr 2007
              • 441

              #7
              I'd worry about that third one. It might be an actual error in some compilers. Don't cast the lvalue at all. Maybe cast the rvalue to a void*?
              One Ring to rule them all. One Ring to bind them.
              One Ring to bring them all and in the darkness interrupt the movie.

              Comment

              • Pete Mack
                Prophet
                • Apr 2007
                • 6883

                #8
                The only thing I can think of is that you are overwriting a function argument rather than a local variable. But I don't see why that should make any difference. In any case, that is an absolutely hideous function. What a crazy, 1980's way to turn '*' into a random name.

                Comment

                • PaulBlay
                  Knight
                  • Jan 2009
                  • 657

                  #9
                  Originally posted by Pete Mack
                  In any case, that is an absolutely hideous function. What a crazy, 1980's way to turn '*' into a random name.
                  You're referring to the first or the second version?

                  'Cuz the first one's Vanilla Angand and the second one's by Atarlost.
                  Currently turning (Angband) Japanese.

                  Comment

                  • PaulBlay
                    Knight
                    • Jan 2009
                    • 657

                    #10
                    Well I got the answer (from a C programming forum).

                    In externs.h
                    Code:
                    extern bool askfor_aux(char *buf, size_t len, bool [COLOR="Yellow"][B](*keypress_h)[/B][/COLOR](char *, size_t, size_t *, size_t *, char, bool));
                    In util.c
                    Code:
                    bool askfor_aux(char *buf, size_t len, bool [B][COLOR="Yellow"](*keypress_h)[/COLOR][/B](char *, size_t, size_t *, size_t *, char, bool))
                    Now compiles with no compiler warnings and the program still works.
                    Currently turning (Angband) Japanese.

                    Comment

                    Working...
                    😀
                    😂
                    🥰
                    😘
                    🤢
                    😎
                    😞
                    😡
                    👍
                    👎