Staredit Network > Forums > SC1 UMS Mapmaking Assistance > Topic: Negative values in CHK format
Negative values in CHK format
Mar 10 2019, 4:05 am
By: sethmachine  

Mar 10 2019, 4:05 am sethmachine Post #1



Hi,

I am very confused by the CHK format (http://www.starcraftai.com/wiki/CHK_Format#.22TYPE.22_-_Map_Type) with the Size field that is supposed to be a U32 (unsigned 32 bit integer). If Size is U32, it means it needs to be interpreted as unsigned. Therefore it makes no sense that it should ever be negative. And I don't understand how to read the CHK file if the Size is negative--I mean do I parse it both as a U32 and signed 32? Just very confused.

Quote
Invalid sections can exist and will be ignored. While Size is unsigned, it can safely be a negative value to read a chunk earlier in the file. This allows for "section stacking", allowing smaller sections to be placed inside of larger ones or duplicate triggers or units to take less space in the file.




None.

Mar 10 2019, 11:52 pm Heinermann Post #2

SDE, BWAPI owner, hacker.

The way integer arithmetic is done, it doesn't matter if it's signed or unsigned. If you add 4294967295 to 1073741824 it becomes 1073741823 because it wraps back to 0 once it exceeds the maximum integer value.




Mar 11 2019, 1:27 am jjf28 Post #3

Cartography Artisan

To illustrate a little more:

Whether it's a u32 or s32 (signed or unsigned) it is just a collection of 32 bits, as either its signed value or its unsigned value the addition operation will come out to the same result (one of the many beautify harmonies the way modern processors were designed).

(u32)v1 + (u32)v2 = v3
(u32)v1 + (s32)v2 = v3
(s32)v1 + (u32)v2 = v3
(s32)v1 + (s32)v2 = v3

Personally I treat the individual section size values as s32, and track my position in the chk while parsing as s64 (cause experimental sizes and no type conversions for my buffer class), that way I need only add the section size (plus 8 for the section header) to my position value to get the next sections position.
https://github.com/jjf28/Chkdraft/blob/feature/fundamental-refactoring/MappingCoreLib/Scenario.cpp#L3696



Rs_yes-im4real - Clan Aura - jjf28.net84.net

Reached the top of StarCraft theory crafting 2:12 AM CST, August 2nd, 2014.

Mar 11 2019, 7:39 pm sethmachine Post #4



If it doesn't matter whether I parse it as signed or unsigned, I am still confused about the "warning" about jump or stacking sections.

From the spec:

Code
Each section begins with an 8-byte header:

u32 Name - A 4-byte string uniquely identifying that chunk's purpose.
u32 Size - The size, in bytes, of the chunk (not including this header)

This allows for "section stacking", allowing smaller sections to be placed inside of larger ones or duplicate triggers or units to take less space in the file.


A negative size doesn't make sense semantically (whether it works out in bit arithmetic doesn't matter), unless Blizzard was trying to do some Python indexing shenanigans (where negative indices start from end of the list, e.g. list[-1] is the last element). If I design a spec or API, the interpretation should be consistent with the value.




Mar 11 2019, 9:55 pm Cinolt Post #5



A unitID or playerID past the normal limit in a Death condition does not make sense semantically either, and most likely were not the original intention of the programmers, but unintended quirks resulting from the code not bounds-checking such data values can be documented (in this case as EUD's).

If they were to recreate semantics from scratch, a sensible thing to do would be to declare the Size field as unsigned and say overflowing values simply are not allowed, and that implementations would abort map loading or whatever in such cases.

But in the long haul software engineers (generally) don't care about that much level of detail, unless it can result in a security exploit which can happen, and aren't really concerned with splitting hairs about exact semantics. If it works, time to move onto making other things that work.



None.

Mar 12 2019, 1:20 am sethmachine Post #6



Quote from Cinolt
But in the long haul software engineers (generally) don't care about that much level of detail, unless it can result in a security exploit which can happen, and aren't really concerned with splitting hairs about exact semantics. If it works, time to move onto making other things that work.

I guess my point-of-view is from the consumer of Blizzard's API, which is irrelevant to them. Obviously they didn't design the CHK format to be used by anyone outside their company.

But there is no way the CHK format spec as it is would ever get past a design or code review for use by a 3rd party. Not to get tangent, but semantics and intentions are pretty important, which is why we use type annotations for all Python code where I work, even though Python isn't a statically typed language.




Mar 12 2019, 4:08 pm Suicidal Insanity Post #7

I see you !

Blizzard never intended people to write or parse the CHKs, and yet people do that and abuse integer overflow to create protected maps.

You mean you don't use python to store None, True, or False in a single value?




Options
  Back to forum
Please log in to reply to this topic or to report it.
Members in this topic: None.
[11:15 pm]
razorback9423 -- I'm just kidding, it's okay about that you made some mistakes.
[11:12 pm]
razorback9423 -- Congratulations Zoan you are a candidate for ban due to spamming.
[10:56 pm]
Zoan -- :wob: code
[10:56 pm]
Zoan -- :wob: :wob: :wob: : :wob: : :wob: : :wob:
[10:56 pm]
Zoan -- :wob: :wob: :wob: : :wob: :wob: :wob: : :wob: :wob: :wob:
[10:56 pm]
Zoan -- :wob: : :wob: :wob: :wob:
[10:55 pm]
Zoan -- no wait I'll do it in 3 messages
[10:55 pm]
Zoan -- it got cut off. I give up
[10:55 pm]
Zoan -- :wob: : :wob: :wob: :wob: : : : :wob: :wob: :wob: : :wob: :wob: :wob: : :wob: :wob: :wob: : : : :wob: :wob: : : :
[10:54 pm]
Zoan -- omg I screwed up again. why isn't there a delete button
Please log in to shout.


Members Online: Roy, razorback9423