[PATCH] Use gtk_tree_model_get_value() to get the index and date of a dive

[Lubomir I. Ivanov]

On 19 September 2012 02:49, Dirk Hohndel <dirk at hohndel.org> wrote:
> "Lubomir I. Ivanov" <neolit123 at gmail.com> writes:
>
>> On 19 September 2012 02:17, Dirk Hohndel <dirk at hohndel.org> wrote:
>>> "Lubomir I. Ivanov" <neolit123 at gmail.com> writes:
>>>> well, unfortunately, in "my book" only. :-(
>>>> i have some experience with truly broken vararg / cdecl compiler
>>>> implementations...
>>>
>>> Ah. We use so many vararg functions in subsurface... if we have to work
>>> around that - oh my. Every printf/scanf function, etc...
>>>
>>
>> yeah,
>>
>> i think, that is why this is a volatile fix and the real cause might
>> be a memory issue. i.e. something writing somewhere, where it
>> shouldn't.
>> very much possible...and annoyingly hard to debug, especially
>> considering the fact that GDB somehow crashes the entire OS (Ubuntu)
>> for me.
>
> Yikes. That's encouraging. You might want to submit THAT to Ubuntu for a
> fix.
>
> The thing that really annoyed me is that Valgrind is seeing anything out
> of the ordinary. Not for the xmlCleanupParser one, nor for this one. If
> we are stomping all over memory, isn't Valgrind supposed to catch that?
>

it should in general catch bad things, but i think the runtimes might
be confusing it a lot. this is definitely the case with windows tools.

> I pushed all the other fixes. I'm still contemplating this one...
>
> There's also Christian's email about cppcheck to look at. Maybe fixing
> those bugs (the ones that actually ARE bugs) will as a side effect fix
> this one?
>
> I've started on the list and am looking for the actual bugs that could
> mess up our memory...
>

there are some memory leaks in parse-xml.c that i've noticed before
Christian's report.

everything else is could be semantics more or less, i'd think.
"gcc -Wextra -pendantic -std=c99" will spit 500+ lines of such if we
really want to tackle them.

"(style) The scope of the variable..." is a bit out of order
considering what ANSI C suggested and what some consider clarity.

it seems not to like gcc attributes much.

"sscanf" for the dates is suspicious, but the dates shouldn't be that
long. there are some buffer lengths to consider in this regard here
though.

"gmtime_r" not so much for a standalones with linear code. would be
worth a shot, somehow...

the "realloc" thing is a bit bad, but not so much. i mean we should
fail if it fails - i.e. "if the mapper cannot provide us with a block,
why even bother".

etc..

static analysis is not that bad in general.

lubomir
--