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
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

Reply via email to