init_player_stats_new_ship used select_primary_weapon and
select_secondary_weapon to assign the player's weapons. However, those
functions read the current weapon and jumped according to its value. A
new ship has no defined value for current weapons, so the jump triggered
an uninitialized value warning from Valgrind.
Add new functions set_primary_weapon, set_secondary_weapon that work
like the previous select_* functions, but always take the path used
for weapons not equal, without checking. This prevents the warnings
from Valgrind, as well as a theoretical risk of initializing the ship
improperly.
gcc generates better code for:
if (variable == magic_constant)
return magic_constant;
than it does for:
if (variable == magic_constant)
return variable;
even though the two have the same result. Switch to the form which
generates slightly better code.
It was a convenient transition macro, but its presence was always
intended to be temporary. Expand it to ease the conversion of usage
sites that already have access to local player data through a local
variable.
It was a convenient transition macro, but its presence was always
intended to be temporary. Expand it to ease the conversion of usage
sites that already have access to local player data through a local
variable.
All callers provide a value which must be a valid weapon number. Cast
the result to a weapon enum so that called helpers can be converted to
expect an enum.
It was a convenient transition macro, but its presence was always
intended to be temporary. Expand it to ease the conversion of usage
sites that already have access to local player data through a local
variable.