Update of bug #15743 (project freeciv):

                  Status:                   Fixed => Ready For Test         
             Open/Closed:                  Closed => Open                   


Follow-up Comment #8:

> value saved as S_LAST of freeciv version that did the save 
> will be restored as S_LAST of freeciv version doing the load.
Ooh, that's deeply cunning. It makes everything much simpler.

Unfortunately, the one place where S_LAST is saved/loaded -- unit pillage
activity -- doesn't actually use special.order[]!
savegame2.c:sg_load_player_unit() reads "activity_target" from the savefile
and directly casts the number into a tile_special_type, rather than
indirecting through special.order[] as it should.

Easily fixed, and probably has not caused a bug yet because we've not
re-ordered the specials for a long time.

Also, I think savegame.c requires the same two fixes (the one already applied
and the one above).

While trying to fix the above, I found more dependencies on the current
specials when loading savegames:
* When loading savefiles, halfbyte_iterate_specials counts enough halfbytes to
fit the current S_LAST, whereas it should count up to the number of specials
in the savefile "specials_vector". If the number of specials were ever to
reduce significantly, this could lead to warnings and incomplete loading of
old savefiles.
* In savegame.c, the number of specials in "specials_vector" is not recorded,
so various accesses to specials_order could cause a buffer overrun.

Attached patch fixes all this. Tested that it doesn't break saving/loading of
specials/activities in S2_2/S2_3 savegames, and that it improves things in
test servers with more / reordered S_*.

(file #15563, file #15564)

Additional Item Attachment:

File name: trunk-robust-special-loading.diff Size:11 KB
File name: S2_4-S2_3-robust-special-loading.diff Size:12 KB


Reply to this item at:


  Message sent via/by Gna!

Freeciv-dev mailing list

Reply via email to