Feature #2187
closedMain: load_ruleset_units(): allow spec_type to be NULL if no specialist entry
0%
Files
Updated by Dean Brown 2 months ago
- File 2187.patch added
Also added a bunch of checks/asserts to avoid a dereference of a nullptr. Hope I got them all.
When this done I will update/improve the 1618_Main.patch in #1618.
Updated by Marko Lindqvist about 1 month ago
- Tracker changed from Task to Feature
- Category changed from Rulesets to General
- Target version set to 3.4.0
Updated by Marko Lindqvist about 1 month ago
In many of those changed places the nullptr check should actually replace old DEFAULT_SPECIALIST check, not add to it, i.e., we want Entertainers (DEFAULT_SPECIALIST) to work correctly too.
Is the requirements.c change even related? Seems wrong in any case, as it does turn invalid (nullptr) specialist in to a valid one (first one / number zero) with no clear justification of why just that one gets selected.
Updated by Marko Lindqvist about 1 month ago
- Status changed from New to In Progress
- Assignee set to Dean Brown
Updated by Dean Brown about 1 month ago
- File 2187.patch added
Yes, requirements.c should not change. I got distracted by the " return 0;" at the end of universal_number() when "there's been an error.". 1 is actually a correct value to return from universal_number(), and is the returned value from specialist_number(source>value.specialist) when source->value.specialist is nullptr.
Might be nice to add a comment to universal_number() saying -1 is possible return value.
Updated by Dean Brown about 1 month ago
My comment got mangled by -1 being interpreted as strike-thru.
Updated by Marko Lindqvist about 1 month ago
Updated by Marko Lindqvist about 1 month ago
- Status changed from In Progress to In Review
- Assignee changed from Dean Brown to Marko Lindqvist
Updated by Marko Lindqvist 30 days ago
- Blocks Feature #2334: city_add_unit(), handle spec_type either nullptr or not added
Updated by Marko Lindqvist 29 days ago
When client connects, server says:
1: Trying to put -1 into 8 bits; it will result 255 at receiving side.
Debugging revealed that this comes from packets_gen.c line
e |= DIO_PUT(uint8, &d_out, &field_addr, real_packet->spectype_id);
Updated by Marko Lindqvist 29 days ago
- Status changed from In Review to In Progress
- Assignee changed from Marko Lindqvist to Dean Brown
Updated by Marko Lindqvist 29 days ago
Likely it's possible to simply change the data type to be sint8 in the network protocol.
Updated by Marko Lindqvist 28 days ago
- Status changed from In Progress to In Review
- Assignee changed from Dean Brown to Marko Lindqvist