[http://sourceforge.net/p/ufoai/bugs/2818 Item 2818] imported from sourceforge.net tracker on 2013-01-28 19:50:51

Can be reproduced with the current master (88e689a49b9315937bd4af3f149211e29f3dd037) by editing campaign.ufo. Just change "pilots [number]" string to the "pilots 0" for one of the difficulty settings and start the campaign game with the same very setting. Game will crash at attempt of placing the first base.
Actual reason for this is the interference of three code fragments:
1) When campaign is started, ccs->eployee[employeeType_t] list pointer is NULL if campaign script says there should be no employees of that type at the beginning (or this employee type is not mentioned in the script at all)
2) LIST_Foreach iterator macro does not change current element pointer ("var") if given a NULL list
3) E_GetUnhired (employeeType_t type) uses that iterator to fins the first jobless employee without clearing employee pointer to NULL, which results in non-initialized pointer when employee list for the given type is NULL, resulting in garbage pointer being returned

Probably, the best method of fixing this will be to to change LIST_Foreach marco so it clears element pointer before scanning the list. It will not only fix this bug, but will prevent similar ones from happening in the future.
===== Comments Ported from Sourceforge =====

====== alextishin (2011-02-21 23:45:58) ======

geever suggests to avoid changing the LIST_Foreach macro, so there is local patch to E_GetUnhired() in 5eb96a9a4dc266086b16fec846f1414c3d2f0c07

====== tlh2000 (2011-02-22 10:29:15) ======

what was the reason for not changing the LIST_Foreach macro?
====== alextishin (2011-02-22 11:56:12) ======

1) Changing macro doesn't fix the bug completely. Original E_GetUnhired() will return last hired pilot if all available pilots are hired. Patch fixes that too.
2) Macro is used at 20+ places, and some piece of code could depend on current behaviour.
3) Changing the macro will make it even more contrived (will have to use ?: operator with a side effect) and geever calls that a black magic. And he' s probably right.
====== tlh2000 (2011-02-23 17:30:50) ======

2) is no reason - if code depends on this behaviour, the code is not very clean

====== sf-robot (2011-03-09 18:20:03) ======

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).