Reply To cazfi
That seems a real bug.
Or maybe not:
effect_list_iterate(get_req_source_effects(&source), peffect) {
...
requirement_vector_iterate(&peffect->reqs, preq) {
...
if (universal_fulfills_requirement(preq, &source) == ITF_YES) {
mypreq = preq;
Iterating only 'get_req_source_effects(&source)' effects should guarantee that there is a requirement matching 'universal_fulfills_requirement(preq, &source)'
Reply To cazfi
Iterating only 'get_req_source_effects(&source)' effects should guarantee that there is a requirement matching 'universal_fulfills_requirement(preq, &source)'
However, despite the reported problem not being there, the "opposite" is. The assumption of exactly one requirement fulfilled by the building breaks the case when the building actually provides solution to multiple requirements (feasible esp. in S3_2/main with the BuildingFlag requirement type). Easy fix to avoid the "exactly one requirement fulfilled" assumption, fixing both the actual bug and the (false positive) warning attached.
Clang analyzer:
../../../../src/ai/default/daicity.c:1720:61: warning: Access to field 'range' results in a dereference of a null pointer (loaded from variable 'mypreq') [core.NullDereference] turns, peffect, cities[mypreq->range], ^~~~~~~~~~~~~That seems a real bug. 'mypreq' is set only when there's a requirement related to the improvement in question, and the above line can be executed even when there is no such requirement.