Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 18 Aug 2002
Offline Last Active Jul 18 2016 11:54 PM

#5235535 Tiny Serialization Library

Posted by MaulingMonkey on 18 June 2015 - 12:35 PM

Most of the low level I/O, if it fails, returns uninitialize data at best (which makes debugging nice and nondeterministic.)

There's no sane bounds checking - it appears trivial to create a tiny file which will eat all your memory when using read_string.

If you're lucky, it will throw std::bad_alloc or dereference null (depending on if exceptions are available or not).  If you're unlucky you'll exhaust all available memory and have OOM crashes later elsewhere.


I wouldn't consider this usable even in a non-hostile environment currently - savegame corruption happens, I don't want it crashing my titles on startup.


In a hostile environment, your attacker will use l=0xFFFFFFFF, the call to new char[0xFFFFFFFF+1] will succeed - it's the same as new char[0] which returns a unique non-null pointer.  The resulting read() call *without* the +1 will then be the start of the buffer overflow, likely probed for possible use in code injection attacks...


Throw SDL MiniFuzz or other fuzzing tools at this if you want to harden it up...

#4965463 Floating Point Constants

Posted by MaulingMonkey on 02 August 2012 - 03:46 AM

Well then it seems highly unlikely you need to worry about loss of precision when converting from float to double, unless your simple arithmetic involves numbers like 23423.4234234098029384233409583405 Posted Image

Of course, do note that simple decimal expressions like "0.3" have an infinite number of digits in binary fraction form and will suffer additional rounding if coerced to float.

#4922740 What's wrong with OOP?

Posted by MaulingMonkey on 16 March 2012 - 09:01 PM

Even ignoring SIMD, interleaving like that makes no sense. In your typical game, you might update the position once per frame per object from velocity, whereas there's a ton of use cases that can end up at higher use counts where you simply don't care about velocity and it's merely wasting cachelines and memory bandwidth at best:

Rendering (both for culling and for setting up transforms)
AI (pathfinding, LOS / sight distance checks, target prioritization)
Gameplay (distance based damage calculations like AoE falloff, fog of war calculations)

With seperate arrays, you're potentially halving your required cache/bandwidth from getting positions if you only care about the position.

Interleaving can speed things up by reducing bandwidth during random access when you're using all the fields, but even then you're going to gain less than nothing by interleaving on a per-component basis.

#4842478 Is'nt scripting maybe a little overated?

Posted by MaulingMonkey on 30 July 2011 - 04:49 AM

1: If you dont use scripting you have to recompile your whole project if you make a change to you code.
I dont know what IDE these people use but when i make a changes to my code only the classes that has changes in them gets recompiled. After i click compile i get a new JAR (i use java) thats ready to be uploaded to my website 1 second later.

C++ projects can take hours for even partial rebuilds if you touch the wrong files, if they're big enough, thanks to the horror that is header files.

2: To make a change to a game entity you just edit its script. To add a new entity you just create a new script.
To make a change to a game entity i just edit a class. To add a new entity i just create a new class. Whats the difference?

Scripting can be set up to allow scripts to be modified/added at runtime. This is sometimes useful (e.g. for seeing the effects of tweaking things immediately and intuitively in realtime)

4: Your moddelers can do lots of cool stuff!
I dont want my moddelers to do lots of cool stuff.

Guess you won't get cool stuff, then.

If you're working solo/near solo and not using C++, scripting probably doesn't help you all that much. Another advantage of scripting, however: Your mission/level/etc scripters can't break the build :)

#4828062 If vs. While

Posted by MaulingMonkey on 26 June 2011 - 07:15 PM

And it's made worse now by the fact that you are now stating that you agree with the important pertinent part of what was posted.

One's entire post should be important and pertinent. There were parts that were correct and parts that were incorrect. This is a tremendously far cry from "totally correct". In mathematics, this wouldn't even be dignified with "partially correct": It'd just be wrong.

And this is how you're being rated. Confirming oversimplifications, inaccuracies, and outright errors could've gotten those confirmations rated up, possibly ending up with a total increase.

Instead we have a tangential, inflammatory, combative, and name calling line of drivel in response to slights that only you perceived, that I doubt convinces any to believe you when you say "I don't want to hi-jack this thread". There are better venues if you truly meant that: Including bringing up ApochiPiQ's supposedly insulting behavior up with him or another moderator directly.

And this is how you're continuing to be rated.

#4779643 reason i love my wife

Posted by MaulingMonkey on 27 February 2011 - 07:00 AM

I think he's still trying to make a point by getting us annoyed that we can't rate him down for a rather asinine post. At least, that's the only thing I can think of for deliberately being a jerk

If that's his plan he seems to be failing rather miserably, considering the number of upvotes he's getting.

#4759863 Pros/Cons for Accessing class members - C#

Posted by MaulingMonkey on 16 January 2011 - 06:31 PM

I have no problem with properties per se; in fact they're very useful for introducing certain types of logic and semantics. But empty properties are worthless.

They allow you to implement interfaces that contains properties, and switching to properties after the fact introduces a number of breaking changes:
Passing by ref will no longer compile (e.g. F( ref foo.Property );)
Writing to individual member fields/properties will no longer compile (e.g. foo.Property.X = 42;)
Calling struct methods that modify the structure will now modify a temporary copy which is discarded rather than the original! (e.g. foo.Property.IncrementX();)

That last point is sticky and subtle enough that I have no problem with anyone who wants to 'future proof' by preferring default properties. This can also be argued for on a consistency basis. Being able to make only the class itself able to modify a property, but still publicly readable, is also very handy:

public int Count { get; private set; }

(All this said, I'm lazy and don't bother with making fields into properties most of the time. And yes, this does mean I spend more time refactoring. In personal practice, only the middle case bites me in the ass.)

#4757656 What Does Everyone Think About The New Site Layout?

Posted by MaulingMonkey on 12 January 2011 - 04:30 AM

Alrighty, we are at 125% line-height right now. When I refreshed the page it did roll up a bit. Still seems readable to me, but we'll see if anyone notices or finds it worse.

Looks good to me.

Hey MaulingMonkey why does the CSS styling you posted list the margin-left property as 235px? We've since edited that down to 185px

Doesn't now. Must've changed while I was preparing my post? Although superpig was ranting about server-side caching in IRC earlier... clarifying right after I cleared my client-side caching testing the black theme at time :D

EDIT: You've got multiple copies of ipb_styles.css, and that was from the black theme.

white theme: http://www.gamedev.net/public/style_css/css_4/ipb_styles.css
black theme: http://www.gamedev.net/public/style_css/css_8/ipb_styles.css

sorry, had to :) but that's about exactly my point: always this negativity, always this "that could go wrong in so many ways!!" how about trying and see if it does? so far, in other fories, it did not go wrong. why should this be different? are we such a bad community?

But did it go right in other forums? I can't think of a single forum I frequently read anymore that has rating up without rating down of any sort. Especially if we're de-emphasizing the per-user aspect of ratings in favor of the actual post contents. But I guess I'm just another negative nancy ;)

#4756271 What Does Everyone Think About The New Site Layout?

Posted by MaulingMonkey on 09 January 2011 - 04:21 PM

Oh my goodness what is this I don't even

#4698533 C++, casting and const

Posted by MaulingMonkey on 29 August 2010 - 07:39 AM

Original post by Ryan_001
This has gone far beyond the original question, that said thanks for all the responses. There seems to be alot of disagreement on what reinterpret_cast can safely do. Now I know shouldn't use it, and I don't in normal code, more I was just curious on what it can do. It seems a bit silly that any use of reinterpret_cast would be undefined/implementation specific, but perhaps I'm wrong here?

I was under the impression casting through reinterpret_cast and back, as long as the alignment and size of the intermediate was appropriate, that you can safely (and in a defined/non-implementation specific way) get the original value back (whatever that may be), and use it. For example:

int a = 5;
void* b = &a;
int c = *reinterpret_cast<int*>(b);

is undefined?

That should be standard defined -- but you could just use a static_cast there as well. Using char* instead of void* (and adding another reinterpret_cast) I believe would be similarly defined behavior.

However, you shouldn't be too suprised if something is undefined, 'unspecified', or implementation defined in C++. For example, which is called first, a or b, in this statement?
f( a(), b() );
Trick question: It's unspecified, and may actually change depending on compiler settings.

Yes, even this simple kind of thing. It's quite maddening [lol]. To worsen matters, take this bit of code:
f( ++(*a), ++(*b) );
People will infer from the above question that the order in which these two values are incremented is unspecified. But it gets worse: If a and b point to the same int (or other intrinsic type), the behavior is outright undefined behavior. In practice, the optimizer will often increment twice before passing either value to f. In theory, it could do anything -- even crash, corrupt memory, or launch nuclear missiles at a cow ranch in Alaska. All perfectly acceptable behavior according to the C++ standard [lol]