hi all.
tree model iterators are easily advanced/setup/created in a way that yields
an invalid iterator, because the denoted location doesn't exist (anymore).
to cath those cases, the tree model API returns booleans indicating success,
but testing those booleans is easily forgotton and a common e
On Fri, 2006-02-17 at 14:29 +0100, Tim Janik wrote:
> to help the compiler catch these mistakes, i've prepared a patch that adds
> G_GNUC_WARN_UNUSED_RESULT to all relevant iterator functions, and intend
> to commit that next week unless objections pop up. in principle it does:
This is pretty ni
On Fri, 2006-02-17 at 11:01 -0600, Federico Mena Quintero wrote:
> On Fri, 2006-02-17 at 14:29 +0100, Tim Janik wrote:
>
>
> > to help the compiler catch these mistakes, i've prepared a patch that adds
> > G_GNUC_WARN_UNUSED_RESULT to all relevant iterator functions, and intend
> > to commit that
On Fri, 17 Feb 2006, Owen Taylor wrote:
On Fri, 2006-02-17 at 11:01 -0600, Federico Mena Quintero wrote:
On Fri, 2006-02-17 at 14:29 +0100, Tim Janik wrote:
to help the compiler catch these mistakes, i've prepared a patch that adds
G_GNUC_WARN_UNUSED_RESULT to all relevant iterator functions
On Fri, 2006-02-17 at 19:52 +0100, Tim Janik wrote:
> On Fri, 17 Feb 2006, Owen Taylor wrote:
>
> > On Fri, 2006-02-17 at 11:01 -0600, Federico Mena Quintero wrote:
> >> On Fri, 2006-02-17 at 14:29 +0100, Tim Janik wrote:
> >>
> >>
> >>> to help the compiler catch these mistakes, i've prepared a p
On Sat, 18 Feb 2006, Owen Taylor wrote:
On Fri, 2006-02-17 at 19:52 +0100, Tim Janik wrote:
i admit that artificial cases where checking the return value is not
required are easily created, but the actual harm involved is just a
mild annoyance. that is in contrast to forgetting to check the r
Tim Janik wrote:
hi all.
tree model iterators are easily advanced/setup/created in a way that
yields
an invalid iterator, because the denoted location doesn't exist
(anymore).
to cath those cases, the tree model API returns booleans indicating
success,
but testing those booleans is easily f
Tim Janik wrote:
tree model iterators are easily advanced/setup/created in a way that
yields
an invalid iterator, because the denoted location doesn't exist
(anymore).
to cath those cases, the tree model API returns booleans indicating
success,
but testing those booleans is easily forgotton a
On 3/21/06, Yevgen Muntyan <[EMAIL PROTECTED]> wrote:
2) When you get path/iterator somehow, with error checking, and thenconvert itto iterator/path. E.g. you can get a path from a row reference, and ifit's not NULL,you know it's a valid path, so you don't need to check return value of
gtk_tree_mod
On Tue, 21 Mar 2006, Yevgen Muntyan wrote:
Tim Janik wrote:
to help the compiler catch these mistakes, i've prepared a patch that adds
G_GNUC_WARN_UNUSED_RESULT to all relevant iterator functions, and intend
to commit that next week unless objections pop up. in principle it does:
These warn
Tim Janik wrote:
did you, or anyone else for that matter, investigate yet whether it'd
be worth
keeping the warnings for *some* of the functions?
I did go through the list, and all the warnings may or may not be bogus
depending
on situation.
gtk_tree_model_get_iter_from_string may look sus
On Thu, Mar 23, 2006 at 03:22:13PM +0100, Tim Janik wrote:
> disabling G_GNUC_WARN_UNUSED_RESULT globally is not what anyone of us had
> in mind i think. i agree with you that the patch should simply be backed
> out where it generates too many warnings.
>
> did you, or anyone else for that matter,
On Fri, 24 Mar 2006, Kristian Rietveld wrote:
On Thu, Mar 23, 2006 at 03:22:13PM +0100, Tim Janik wrote:
disabling G_GNUC_WARN_UNUSED_RESULT globally is not what anyone of us had
in mind i think. i agree with you that the patch should simply be backed
out where it generates too many warnings.
13 matches
Mail list logo
