Welcome to the Builder Academy

Question Is int i in load_affects() of players.c being optimized away?

More
Yesterday 17:15 - Yesterday 17:30 #11060 by krell
Originally, the compiler complained that the variable was initialized but not used. I set it to zero just to see if it would help, but it merely changed from initialized but not used to set but not used.

players.c:975:86: error: variable 'i' set but not used [-Werror,-Wunused-but-set-variable]

  975 |  int num = 0, num2 = 0, num3 = 0, num4 = 0, num5 = 0, num6 = 0, num7 = 0, num8 = 0, i = {0}, n_vars = {0};


function load_affects():
Code:
static void load_affects(FILE *fl, struct char_data *ch) {   int num = 0, num2 = 0, num3 = 0, num4 = 0, num5 = 0, num6 = 0, num7 = 0, num8 = 0, i = {0}, n_vars = {0};   char line[MAX_INPUT_LENGTH + 1];   struct affected_type af = {0};   do {     new_affect(&af);     /* As in load_skills: without this the loop never ends, and each turn      * of it calls affect_to_char(), so the list grows until memory runs      * out rather than merely hanging. */     if (!get_line(fl, line, sizeof(line)))       break;     n_vars = sscanf(line, "%d %d %d %d %d %d %d %d", &num, &num2, &num3, &num4, &num5, &num6, &num7, &num8);     if (n_vars < 1)       break;     /* An affect's spell number runs to TOP_SPELL_DEFINE, which is the size      * of spell_info[] -- not to MAX_SKILLS, which bounds the skills array      * and is a smaller, different thing.  SPELL_DG_AFFECT is 298, so a      * player carrying a script-applied affect saves one above MAX_SKILLS      * as a matter of course. */     if (num > TOP_SPELL_DEFINE) {       log("SYSERR: load_affects: spell %d out of range in %s's pfile", num,           GET_NAME(ch) ? GET_NAME(ch) : "a player");       continue;     }     if (num > 0) {       af.spell = num;       af.duration = num2;       af.modifier = num3;       af.location = num4;       if (n_vars == 8) {              /* New 128-bit version */           af.bitvector[0] =  num5;           af.bitvector[1] =  num6;           af.bitvector[2] =  num7;           af.bitvector[3] =  num8;       } else if (n_vars == 5) {       /* Old 32-bit conversion version */         if (num5 > 0 && num5 < NUM_AFF_FLAGS)  /* Ignore invalid values */           SET_BIT_AR(af.bitvector, num5);       } else {         /* Not a shape this format has.  sscanf leaves the fields it could          * not fill alone, so duration, modifier and location would be          * whatever the record before this one put there -- an affect          * wearing the previous affect's values.  It was logged and then          * applied regardless.  build_player_index() above refuses a short          * record for exactly this reason. */         log("SYSERR: Invalid affects in pfile (%s), expecting 5 or 8 values", GET_NAME(ch));         continue;       }       affect_to_char(ch, &af);       i++;     }   } while (num != 0); }

It looks like i is expected to be used, but I think the compiler is optimizing it away. I was able to force the compiler to use i by declaring it a volatile integer. 
Code:
static void load_affects(FILE *fl, struct char_data *ch) {   int num = 0, num2 = 0, num3 = 0, num4 = 0, num5 = 0, num6 = 0, num7 = 0, num8 = 0, n_vars = {0};   volatile int i = {0};

Is i still necessary for this function to work correctly? If it isn't, removing it would be cleanest but it looks like it might be important. 
Last edit: Yesterday 17:30 by krell. Reason: I didn't like the look of the formatting and I corrected the title

Please Log in or Create an account to join the conversation.

More
Yesterday 20:39 #11061 by thomas
Indeed it is being optimized out; it has no side effects. One use could be to log the number of affects loaded:
Code:
} while (num != 0); log("info: Loaded %d affects to %s", i, GET_NAME(ch)); }

Whether this is useful is another matter. I suggest just removing the variable entirely.
The following user(s) said Thank You: krell

Please Log in or Create an account to join the conversation.

Time to create page: 0.519 seconds