[Kde-bindings] comparing a Qt object with nil causes a crash in korundum4

[Stefano Crocco]

Alle Sunday 16 November 2008, Arno Rehn ha scritto:
> On Sunday 16 November 2008 10:43:23 Stefano Crocco wrote:
> > Alle Sunday 16 November 2008, Cyrille Berger ha scritto:
> > > On Sunday 16 November 2008, Stefano Crocco wrote:
> > > > This happens with:
> > > > * Gentoo linux
> > > > * gcc version 4.3.2 (Gentoo 4.3.2 p1.0)
> > > > * Qt 4.4.2
> > > > * ruby 1.8.7 patchlevel 72
> > > >
> > > > Note that this behaviour didn't occur with previous revisions of
> > > > korundum4 (I'm almost sure it worked with revision 874468).
> > >
> > > I won't be so sure, I use a "old" kdebindings r831805 which is more or
> > > less kdebindings 4.1.0. And I get the crash too. (well of course it
> > > could have been fixed in the mean time and then broken again).
> >
> > I'm sure the bug wasn't there in revisions around 874468: the program I'm
> > writing was working correctly with it, but as soon as I upgraded to the
> > latest one, it started crashing. If you say it was already there in
> > revision 831805, I suppose you're right in thinking it has been fixed and
> > broken again.
>
> Mh, I can't think of any commit that could've fixed/broken it. Since the
> bindings will try one of the overloaded operator== methods (which always
> expect a valid reference, iirc), we would need to special case the ==
> operator in ruby. In the meantime you can use Object#nil? - that should
> work equally well.

The problem is that I want to check if two things are equal, so I do:

if obj1 == obj2
...
else
...
end

Either obj1 or obj2 can be nil, though, so my program crashes. However, I can 
easily work around this: I'll first check that obj2 isn't nil and only do the 
equality check otherwise. By the way, reversing the order of the operands 
doesn't cause a crash:

nil == Qt::Point.new(1,2)
=> false

Stefano