Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CHGrunt::CheckMeleeAttack1 does not properly initialize variable #3176

Open
SamVanheer opened this issue Nov 29, 2021 · 1 comment
Open

CHGrunt::CheckMeleeAttack1 does not properly initialize variable #3176

SamVanheer opened this issue Nov 29, 2021 · 1 comment

Comments

@SamVanheer
Copy link

CHGrunt::CheckMeleeAttack1 does not properly initialize a local variable:

halflife/dlls/hgrunt.cpp

Lines 413 to 434 in c7240b9

BOOL CHGrunt :: CheckMeleeAttack1 ( float flDot, float flDist )
{
CBaseMonster *pEnemy;
if ( m_hEnemy != NULL )
{
pEnemy = m_hEnemy->MyMonsterPointer();
if ( !pEnemy )
{
return FALSE;
}
}
if ( flDist <= 64 && flDot >= 0.7 &&
pEnemy->Classify() != CLASS_ALIEN_BIOWEAPON &&
pEnemy->Classify() != CLASS_PLAYER_BIOWEAPON )
{
return TRUE;
}
return FALSE;
}

If m_hEnemy is null then pEnemy will be uninitialized.

Note that CheckMeleeAttack1 is normally called only if m_hEnemy is not null, but it is possible for other AI routines to clear this handle between the initial check in the base AI code and this function.

To fix this the code needs to be changed to this:

bool CHGrunt::CheckMeleeAttack1(float flDot, float flDist)
{
	CBaseMonster* pEnemy = nullptr;

	if (m_hEnemy != NULL)
	{
		pEnemy = m_hEnemy->MyMonsterPointer();
	}

	if (!pEnemy)
	{
		return false;
	}

	if (flDist <= 64 && flDot >= 0.7 &&
		pEnemy->Classify() != CLASS_ALIEN_BIOWEAPON &&
		pEnemy->Classify() != CLASS_PLAYER_BIOWEAPON)
	{
		return true;
	}
	return false;
}
LogicAndTrick pushed a commit to LogicAndTrick/halflife-updated that referenced this issue Dec 26, 2021
@SamVanheer SamVanheer reopened this May 23, 2023
@SamVanheer
Copy link
Author

SamVanheer commented May 23, 2023

In case anybody's wondering why a bunch of issues were just reopened: when i fixed issues in my own projects i marked them as having fixed these issues using Resolves #id syntax. Github retroactively closed a bunch of issues as a result. When i found out about this i stopped using that syntax but i've now gone through and reopened the issues that were closed in error.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants