[PATCH] Use long instead of int when retrieving DIVE_DATE via gtk_tree_model_get

[Lubomir I. Ivanov]

On 20 September 2012 07:48, Linus Torvalds
<torvalds at linux-foundation.org> wrote:
> On Wed, Sep 19, 2012 at 5:41 PM, Linus Torvalds
> <torvalds at linux-foundation.org> wrote:
>>
>> I pushed out an RFC commit into the "time-function" branch, if
>> somebody wants to take a look. Hmm?
>
> Btw, Lubomir, since I obviously never actually saw the problem, mind
> giving that "time-function" branch a test on your setup?
>
> I just pushed out the equivalent fix in that branch (and I'd pushed
> out your "int"->"long" fix on master earlier). The original commit in
> that time-function branch only did the 64-bit time, it didn't actually
> fix the use of the wrong type. And then I had to go to my kids school
> function, so I only now pushed out the thing that fixes the problem
> you found there. Mind testing?
>
> (Miika too, I guess, since he was the original reporter).
>
> I'm not entirely sure that it's even worth worrying about the whole
> year-2038 bug, but since the new 64-bit time handling should also get
> rid of the worry about the non-reentrancy of gmtime(), it does seem to
> solve multiple issues in one go. Which is a sign of something good.
>

good day,

just took a look at the branch.
the new implementation with a local utc_mkdate seems much safer, also
G_TYPE_INT64 is the way to go.
like you've said this seems to solve multiple issues.

while testing i've only noticed a couple of warnings when compiling on
a 32bit system.
(attached test patch)

but then i realized for the warning in FIND_TRIP to be gone i truncate
the timestamp_t value (8byte) to 32bit then pass it to gconstpointer
input of g_list_find_custom()
(which is of type "const void *" = 4byte eax / x86).

perhaps this problematic part should be moved to a function (i.e. make
FIND_TRIP a function and use unions), but there could be other
solutions.
i also wonder how reliable g_list_find_custom() will be is in this
regard on 32bit systems...

lubomir
--
-------------- next part --------------
A non-text attachment was scrubbed...
Name: time_warnings.patch
Type: application/octet-stream
Size: 1627 bytes
Desc: not available
URL: <http://lists.hohndel.org/pipermail/subsurface/attachments/20120920/d66e5ebb/attachment.obj>