scary changes...

[Willem Ferguson]

I have driven this one around a few blocks and it did not misfire even once.
Kind regards,
willemf


On 14/11/2013 12:46, Dirk Hohndel wrote:
>
> Here's the commit message of the last commit I just pushed:
>
> commit ed41d5a74490b9af03ece57015d6867bbf00df14
> Author: Dirk Hohndel <dirk at hohndel.org>
> Date:   Thu Nov 14 19:36:41 2013 +0900
>
>      Sort the dive table after adding a dive
>      
>      This commit scares me. Any pointers to dives or indices into the dive
>      table... anything like that is invalid after we resort the table. Well,
>      not technically "invalid" (as in bad pointers), but after re-sorting the
>      table these will possibly not be pointing at what we expected.
>      
>      This starts with the selection being "wrong" after we add a dive that
>      isn't the last dive (once we click OK the chronologically last dive will
>      be selected).
>      
>      But of course without doing this, our #1 assumption about the dive_table
>      is broken. The dive_table is supposed to be in chronological order.
>      
>      Best advice of course would be "don't enter dives out of order" - but of
>      course that's not realistic.
>      
>      Fixes #234
>      
>      Signed-off-by: Dirk Hohndel <dirk at hohndel.org>
>
>
> I am reasonably certain that this is the right thing to do, but as the
> commit message indicates, I'm rather worried about the consequences.
> I have stared at this code for too long and would really appreciate some
> others (especially Linus...) to take a look.
>
> We do make the assumption that our dive_table is sorted in various
> places (that's how the bug report #234 pointed me to this... if you add
> dives out of chronological order you get negative time intervals between
> dives... oops). But sadly we also have the habit of keeping either dive
> indices (things like selected_dive) or (far worse) pointers to dives
> around in memory. We should NEVER do the latter (except for time periods
> where we KNOW that the dive_table won't be modified). The former
> is /usually/ ok, but will still end up causing trouble if we for example
> merge two dives or (as in this case) add dives in the middle of the
> dive_table.
>
> Please test.
>
> /D
>
> _______________________________________________
> subsurface mailing list
> subsurface at hohndel.org
> http://lists.hohndel.org/cgi-bin/mailman/listinfo/subsurface
>