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.

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.

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)v₁ + (u32)v₂ = v₃
(u32)v₁ + (s32)v₂ = v₃
(s32)v₁ + (u32)v₂ = v₃
(s32)v₁ + (s32)v₂ = v₃

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

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:



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.

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.

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.

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?