This corrects an issue encountered when loading world information on the Raspberry Pi. Sometimes, there is a ~ stored in the memory location in front of tmp char array. The for loop will decrement below the starting memory address, making it read the ~ and think it's at the end of the room, causing an error and preventing the MUD from loading.
This change checks the memory address of tmp, ensuring it is > the starting memory address before decrementing it in the for() loop. Then, the if/else checks to ensure the carriage return and newline are properly placed to prevent duplication.
* 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.
* fix gcc warning: truncation in strncat
In file included from /usr/include/string.h:494,
from sysdep.h:74,
from act.item.c:12:
In function ‘strncat’,
inlined from ‘name_from_drinkcon’ at act.item.c:804:5,
inlined from ‘name_from_drinkcon’ at act.item.c:769:6:
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:136:10: warning: ‘__builtin_strncat’ output truncated before terminating nul copying as many bytes from a string as its length [-Wstringop-truncation]
136 | return __builtin___strncat_chk (__dest, __src, __len, __bos (__dest));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
act.item.c: In function ‘name_from_drinkcon’:
act.item.c:797:16: note: length computed here
797 | cpylen = strlen(cur_name);
| ^~~~~~~~~~~~~~~~
* Whitespace cleanup before bugfix
* Fix warnings for gcc-9.2.1
Also, fixed an ancient FIXME and a known bad strcat usage.
spell_parser.c: In function ‘say_spell’:
spell_parser.c:135:75: warning: ‘%s’ directive output may be truncated writing up to 255 bytes into a region of size 216 [-Wformat-truncation=]
135 | snprintf(buf1, sizeof(buf1), "$n stares at you and utters the words, '%s'.",
| ^~
In file included from /usr/include/stdio.h:867,
from sysdep.h:69,
from spell_parser.c:12:
/usr/include/x86_64-linux-gnu/bits/stdio2.h:67:10: note: ‘__builtin___snprintf_chk’ output between 43 and 298 bytes into a destination of size 256
We're leveraging the lookup table, because it's a safer way
to see if an object has been free'd than looking at the object
itself (which while it may work may just as well fail).
Fixes#83
* 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
* 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.
* Make sure %target% works in act triggers
* code cleanup. Remove inline block, make variable names more understandable.
Ref https://www.tbamud.com/forum/4-development/4525-confused-over-piece-of-code-in-parse-room
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.
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.
This should be my last batch of these big fixes.
That's not to say there aren't still more things to fix. There
certainly are. But, I expect my future fixes will be smaller.
Full internationalization would be much cooler, but that's never going
to happen. Given that, this will at least prevent folks from constantly
having to look and switch between typing "armor" and "armour", depending
on which zone each item originated in, etc.
I could flip these either way, but a survey of the current state shows
that about 80% of the mixed cases use the American spellings, while 20%
use the British. And, most words *only* exist in this data in their
American forms. So, it seems the majority prefer these spellings.
In case anyone likes trivia:
* The most common mixed words in here were "armour" and "colour", each of
which occured about half as often as "armor" and "color", respectively.
* The most British word in here was "theatre" (including other forms),
which occured about twice as often as "theater".
This stanardizes all of these (and other forms of these same words):
* armour -> armor
* colour -> color
* favour -> favor
* honour -> honor
* civilise -> civilize
* centre -> center
* theatre -> theater
* defence -> defense
* offence -> offense
* realise -> realize
Functionally, this is a non-change.
This just conforms a few odd cases to be the same as the rest.
`git show -w` shows nothing (this is a whitespace-only change).
Since circle/tba is not case-sensitive, this should be a non-change.
I confirmed this by verifying that `diff -i` shows zero changes.
So, to tba, this is just a cosmetic cleanup.
However, to others that use this data, the case might be important.
...this includes my own separate MUD codebase. :)
This just converts the few DOS text files still in here to standard text files (line-endings),
removes all the trailing spaces on lines, removes all the trailing blank lines, and replaces
all the tabs (except in .zon files, where they seem to be common) with expanded spaces.
It's easy to confirm this is actually a non-change, except for whitespace:
* `git show -w` shows this commit as only removing 8 trailing blank lines.
This should make no difference to tbaMUD itself, but it will make working on these files,
especially with scripts and automated tools, much easier.
This is the base change for a set of other changes I will put up once/if this merges,
without this, the others are just too complicated to wrangle.
These are mostly cases of confusion between the "on the body"
and "about the body" slots (5 and 12).
But, there are also some that seem to just be misconfigured,
like non-weapons being wielded, worn items being unwearable,
weapons being worn instead of wielded, and items being worn
instead of held.
I have an independent MUD codebase that reads these files, and
so this gives me an ability to somewhat orthogonally test these,
and easily find this sort of issue.
I did avoid all the cases where it was clear this was done
intentionally, like all the cases where the second neck was
used for the missing face slot (masks, etc).
The ones fixed here all seem to really be (minor) bugs.
I don't know dg_script well at all, so I could be mistaken.
But, I think these are just minor errors in this script.
I have a separately-implemented mud codebase that interprets the
worlds from tbamud, and it flags these as errors, and some other
issues I might chose to fix later, depending on how this PR goes. :)
Of course, it's possible this is really a bug in my own codebase, and
not in these scripts... but I don't think so - and the documentation
I've managed to find seems to confirm my suspicion.
I am guessing some script or tool used upstream is doing an unsafe
search-and-replace for '@' with TAB, and accidentally changing these.
They seem to have been creeping into the repo for years.
I produced this fix commit automatically with:
sed -i 's|\t\([bcdgmnoruwyBCDGMRWY]\)|@\1|g' tba/*/*.*
...and then a few files' changes had to be undone.
I looked through all of the rest, and they look like correct fixes.
I also ran all the other letters, and they only make incorrect "fixes".
* make Makefile more portable
tbamud doesn't build on FreeBSD or OpenBSD. This series of commits are meant to make those builds work by making the Makefile more portable.
I should mention that I've never used tbamud before today, so please read my pull request carefully.
This commit itself fixes the first issue encountered. I assume wildcard and patsubst are gmake-only.
* Update Makefile.in
It turns out using the backslash to escape newlines in this situation is not portable.
* Delete Makefile.in
Will re-add. There are problems with this file. It's marked executable when it shouldn't be, and has ^M characters which prevent builds on OpenBSD.
* re-add Makefile.in
* Add build generated files to .gitignore
* Fix error in "last all" output and resolve Wunused-result warnings
- Check return value of several standard library calls that could
return error states.
- Fix issue with "last all" command (it sent tabs for alignment
that were reinterpreted as colors).
* Fix buffer overflow in do_export_zone command
* Replace a few strcat/sprintf instances with bounded variants
Also cleaned up the whitespace in the parse_edit_action function as it was
not consistent.
Fix bug in editor format command introduced in earlier commit
* Fix bug in editor toggle command when an escaped @ is in the buffer
Previously, toggling between @ and \t would always try to convert
@ to \t, even if already toggled, iff an escaped @ was present in the
buffer (i.e. '@@').
Replace a few sprintf calls with snprintf to prevent buffer overflow.
Added error messages to the logs where buffer size prevents a room,
object, mobile, or quest from being saved to disk.
* Fix several misleading indentation warnings on GCC 8.1.1
* Fix reliance on undefined strcpy/sprintf behavior (-Wrestrict warnings)
The standard states that strcpy results in undefined behavior when the source
and destination buffers overlap. I resolved this with a combination of memmove
and strlen. Note that the resulting code is slightly less efficient.
Similarly, sprintf's behavior is undefined when copying takes place between
objects that overlap. I replaced most of these with a simple strcat, though
one required a temp buffer.
* Fix format in improved-edit.c to match surrounding code
