-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Integer bounds in various places! Does the engine wrap or throw error on too-big family/genus/species/event numbers? And if wrapping, does anyone's code rely on that? #38
Comments
I know Species wraps around, so I assume genus and family do too. Events in scrp also wrap around instead of erroring |
Also negatives in Event just wrap around, (Like Event will wrap around if you give it a negative) |
Awesome, thanks! :D |
Creatures Village has an agent with classifier Also in Creatures Village, a couple agents in |
Oh great! :D I wonder if plane is unsigned 32bit? |
plne wraps around to negative with that number, but it is signed in DS, so it's either a change or Someone just put a really big number for plane in CV. |
I'm pretty sure Family is a uint8_t, Genus is a uint8_t, Species is a uint16_t, and Event is a uint16_t, but I could be very wrong about that! Let's say checking those bounds is also part of the question :3
And also negative numbers. I assume those are never allowed, right?! That might even be a syntax error in some places (like SCRP)!
And all this applies to other values too! Like all integer variables with SETV, and storing extra data in ATTR or BHVR (even though only certain bits are actually used—are there more bits? is it okay if there were even more?), and "AVAR OWNR 100", and etc.!
(For clarity and posterity, uint8_t means [0, 255], uint16_t means [0, 65535], and uint32_t means [0, 4294967296], and int32_t means [-2147483648, 2147483647], all including both bounds and everything in between)
So if it doesn't wrap or if it does but wrapping is never relied on by anyone, we can just say "portable CAOS code never uses numbers out of range and never relies on them wrapping" ie "never relies on them being supported and never relies on them being unsupported either!" XD
And then an engine implementation can use bigger bounds (like a uint32_t or an int32_t for all three) if it wanted and still be "standards compliant" by a made-up standard we may or may not decide on XD
The text was updated successfully, but these errors were encountered: