Another Engine Crasher...

[mh]

[leileilol]

Thanks i'll keep that in mind!! Stability seems underrated in all these quake engines these days, so much volatile going on

[Baker]

Thanks for the info. I know I do not like the vague "this buffer size is X bytes" hardcoding stuff and have sought to try to reduce its usage.

[szo]

Bumping the array size is not a solution. Make COM_FileBase() buffer size safe. (see quakespasm svn r554, for e.g.)

[revelator]

[szo]

[revelator]

dont remember where i got the above function but its been in my realm engine for years now.
the size_t idea might come in handy in my own engine since this ones a bit bloated (works though)
but it needs a strlcpy implementation which does not exist normally on windows, so i used the one from darkplaces.

[szo]

[mh]

szo is correct here, but with the observation that in this particular case you're not going to be exceeding the limits of MAX_OSPATH to begin with (and within a pak file you'll never exceed 56 chars - including the NULL terminator - as the format won't allow you to). Bumping the array size is good enough for a quick and dirty fix (but in both cases, and as COM_FileBase is used to generate a hunk tag, you need to ensure that copying off the hunk tag to your hunk block is also robustly handled).

When it comes to stripping extensions/etc I personally prefer to work backwards through the string, as it more robustly catches the case where a directory name may have a '.' in it (and it's easier to catch the relevant path delimiter this way too).

[revelator]

I kinda remember i used this version because the old one would bitch like hell with my pk3 code hmm.

[szo]

[revelator]

aye that was it damn thing just started looping untill it crashed.
a safer version is definatly a must in those cases.