kyonshi/tbamud
1
0
Fork 0
mirror of https://github.com/tbamud/tbamud.git synced 2026-02-20 02:21:44 +01:00
Code Issues Packages Projects Releases Wiki Activity

GitHub issues 78 79 81 num aff flags off by one (#82)

Browse Source 
* Make sure all followers are free'd before freeing the character list

Otherwise, the followers structs will point to free'd memory and
the stop_follower call will attempt to dereference a free'd
characters' followers list.

* https://github.com/tbamud/tbamud/issues/79 typo

* https://github.com/tbamud/tbamud/issues/81 nullpointer crash on syntax check run

* NUM_AFF_FLAGS fix.

Now, consistently, the NUM_AFF_FLAGS is used in the same way as other
NUM_* variables. Specifically, the the number is consistent with
how others are defined - 1 above the highest in the list.

I would like to have removed the need to start from 1 instead of 0
as well, but the loading mechanism, and thus potentially a lot of
existing object files, use 0 as a marker for "no flags set", and
we can't easily fix that. So, the places we loop through the list,
we still need to make sure we're stying within the [1;NUM_AFF_FLAGS) interval.

Simultaneously, I've checked over the other flags, and it seems like
the usage is pretty consistent there.

Fixes https://github.com/tbamud/tbamud/issues/78
This commit is contained in:
Thomas Arp
2020-02-26 00:39:29 +01:00
committed by GitHub
parent 7f0acefcb4
commit eb650c2811
9 changed files with 17 additions and 21 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
src/oedit.c
View File

@@ -936,7 +936,7 @@ void oedit_parse(struct descriptor_data *d, char *arg)
case OEDIT_PERM:
if ((number = atoi(arg)) == 0)
break;
if (number > 0 && number <= NUM_AFF_FLAGS) {
if (number > 0 && number < NUM_AFF_FLAGS) {
/* Setting AFF_CHARM on objects like this is dangerous. */
if (number != AFF_CHARM) {
TOGGLE_BIT_AR(GET_OBJ_AFFECT(OLC_OBJ(d)), number);