qbismSuper8 alpha 061410 released

[Baker]

The "z" in "Q_snprintfz means that it null terminates it).

I did not know that.

If I read it correctly MicroSoft's _snprintf does not guarantee null termintation as gcc's snprintf does. http://msdn.microsoft.com/en-us/library/2ts7cx93.aspx

One option is to do ...

Code: Select all

#ifdef _WIN32
#define snprintf Q_snprintfz ...


In my humble opinion the reason it is better to have snprintf everywhere instead of Q_snprintfz is because it is one less thing someone who knows C has to explore when using your source code.

So I've jettisoned Q_strcpy, Q_strlen, Q_atof and virtually every Quake version of standard C string functions.

[Spike]

one reason for the Q_ blah functions - speed.
_snprintf does not terminate, this is consistant with strncpy/strncat.
note that the return values also differ, so consider casting that to void, before you ever depend upon any behaviour...

[frag.machine]

One option is to do ...

Code: Select all

#ifdef _WIN32
#define snprintf Q_snprintfz ...


In my humble opinion the reason it is better to have snprintf everywhere instead of Q_snprintfz is because it is one less thing someone who knows C has to explore when using your source code.
So I've jettisoned Q_strcpy, Q_strlen, Q_atof and virtually every Quake version of standard C string functions.

OTOH, people that doesn't know this detail when working with your code will assume they are dealing with the normal versions of snprintf() and alike, and thus will rely in behaviors they know do exist in those standard implementations (but that may not exist in the hidden Quake counterparts). Hello, misterious crashes and random buffer overflows!

The reasoning behind the Q_* functions is quite simple: portability. Things that may or not exist (or even behave differently) from one OS to other are nicely wrapped and guaranteed to behave the same across platforms to anyone who just sticks to the Q_* API.

[mh]

Personally I've come to prefer the Q_* versions of the functions as you can also add stuff like checking for NULL pointers. Ever tried calling a CRT string function with a NULL pointer? Loads of fun. And it seems as though it something happens in PF_VarString (which doesn't call a Q_strcat but probably should).

[Spike]

PF_VarString can't normally distinguish between floats, string constants, string pointers inside the engine code, or strzoned strings.
It'll potentially crash whatever happens. Besides, stringtable+0 = "" always, so null checks or not, makes no difference.

[Baker]

Interesting points of view. My main reason I removed the Q_ functions was that DarkPlaces has them removed and I have historically looked to DarkPlaces to try to pick up better ways to do things.

Are the Q functions actually faster? Like is Q_strlen faster than strlen and so on?

[frag.machine]

Interesting points of view. My main reason I removed the Q_ functions was that DarkPlaces has them removed and I have historically looked to DarkPlaces to try to pick up better ways to do things.

Are the Q functions actually faster? Like is Q_strlen faster than strlen and so on?

IMO The problem is not removing the Q_*() and replacing it with calls to standard (and maybe OS-specific functions, like DirectQ does with memory management, for example); the real harm is to silently add the macros to pretend you're using CRT stuff. Everything may be working just fine now, but later mysterious bugs can sprout and you won't remember about this little hack.

[Baker]

IMO The problem is not removing the Q_*() and replacing it with calls to standard (and maybe OS-specific functions, like DirectQ does with memory management, for example); the real harm is to silently add the macros to pretend you're using CRT stuff. Everything may be working just fine now, but later mysterious bugs can sprout and you won't remember about this little hack.

I haven't redefined a single standard C function in ProQuake or Engine X, with the exception of #define snprintf _snprintf for Windows.

I may end up replacing them all with the DarkPlaces equivalent for clarity. I may have posted a bad idea, but I'm not into bad coding practices. (Even then ... is there much difference under Windows redefining snprintf to _snprintf versus, say, Q_snprintfz? Not really.)

I'm in agreement with a lot of the sentiments expressed in this thread, but at the same time OS X and Linux use GCC which requires no redefinitions to compile my code. Besides, I really should have a mingw + gcc build file for my engines ... I just have limited time and have to pick and choose my priorities.

[frag.machine]

IMO The problem is not removing the Q_*() and replacing it with calls to standard (and maybe OS-specific functions, like DirectQ does with memory management, for example); the real harm is to silently add the macros to pretend you're using CRT stuff. Everything may be working just fine now, but later mysterious bugs can sprout and you won't remember about this little hack.

I haven't redefined a single standard C function in ProQuake or Engine X, with the exception of #define snprintf _snprintf for Windows.

Sorry if I sounded a bit harsh, wasn't really my intention. But what you wrote in your initial comment leaded me to believe you were actually redefining a lot of critical functions in a silent way, which can be a very hazardous path to choose - specially when there are a number of beginners using your code as base or at least reference to create their own projects, it's important to give good examples.

Regarding performance, I suspect they probably won't be better than their native counterparties. A benchmark would be required to confirm this though.

[mh]

I don't see any harm in asking these questions or in putting forth these ideas; it's a good springboard for discussion and we can all get the benefit of everyone's accumulated knowledge this way. Keep it up!