Follow-up Comment #19, bug #18087 (project freeciv): I'm working my way through a lot of new messages. Furthermore all of my all patches have to be rebased to the current trunk - a lot happend in the last half year!
> trunk-S2_3-hugemap-stack-overflow.diff Thanks for working on this patch - this on looks good! I'm compiling current trunk at the moment. > I only noticed one: in sg_load_map_known()), SAVE_MAP_CHAR() -> sg_failure_ret() -> sg_check_ret() can return prematurely. I will try to find a way to handle such cases. Would it help to add a (possible) goto action to the macro, i.e goto CLEANUP? > trunk-S2_3-hugemap-colatitude.diff The changes in apgen.c only prevent division by 0 errors. If I remember correctly, the change in mapgen_topology.h tries to addaped the map generator for the bigger size (try a size of 32x500 or 500x32 ...). It is only needed if the map size is increased further (patch 3). > trunk-S2_3-hugemap-biggermaps.diff Yeah, this is for trunk or for people who need such a big map (akfaew?). > Aside: I think the correct way to express the relationship > between MAP_MAX_SIZE and MAX_DBV_LENGTH is to publish the > latter in bitvector.h and have a static (compile-time) assert > in the map code. But we don't seem to have a static assert > mechanism yet. I may look into it. Is there something like #error? It could stop compilation if the check fails ... _______________________________________________________ Reply to this item at: <http://gna.org/bugs/?18087> _______________________________________________ Nachricht geschickt von/durch Gna! http://gna.org/ _______________________________________________ Freeciv-dev mailing list Freecivemail@example.com https://mail.gna.org/listinfo/freeciv-dev