From kde-devel Fri Oct 17 21:49:39 2008 From: "David Boosalis" Date: Fri, 17 Oct 2008 21:49:39 +0000 To: kde-devel Subject: Re: Fix for kfilewidget.cpp Message-Id: <870c99310810171449o56cfc5d1y51af269c26eb693c () mail ! gmail ! com> X-MARC-Message: https://marc.info/?l=kde-devel&m=122428024805683 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============0117651825==" --===============0117651825== Content-Type: multipart/alternative; boundary="----=_Part_59728_29326842.1224280179546" ------=_Part_59728_29326842.1224280179546 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Rafael. Maybe some one more intimate with kword can address this issue. I've seen this problem for sometime with koffice in SVN and that's why I peaked a little under the covers to see what it is the matter. Eventually they have to address it, or maybe it's just my system and this is all a mute point. I agree with you that null pointers should never happen, but it did, they do, and they always will as long as you are writing new code. So why not prevent seg faults from occurring by doing simple checks where ever practical, and this is surely a practical case as the code in question is seldom called If I find out anything more I will pass it on. Regards, David On Fri, Oct 17, 2008 t 2:25 PM, Rafael Fern=E1ndez L=F3pez : > Hi, > > My origonal post has a fix that got around this core dump, ie doing chec= ks >> for null pointers. >> > > I know... but my point is that a 'null pointer' should never happen there > (since d is assigned on KFileWidget constructor, and thus, is never null)= . > > It would be great some context information on the backtrace (like, what > KOffice code did the call), also it is crucial to know where exactly on t= he > showEvent() the dump happened. > > I prefer to understand the problem deeply than adding a null pointer chec= k > blindly that we don't actually understand why is it happening. > > > Regards, > Rafael Fern=E1ndez L=F3pez. > ------=_Part_59728_29326842.1224280179546 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Rafael.
Maybe some one more intimate with kword can add= ress this issue.  I've seen this problem for sometime with koffice= in SVN and that's why I peaked a little under the covers to see what i= t is the matter.  Eventually they have to address it, or maybe it'= s just my system and this is all a mute point.

I agree with you that null pointers should never happen, but it did, th= ey do, and they always will as long as you are writing new code.  So w= hy not prevent seg faults from occurring by doing simple checks where ever = practical, and this is surely a practical case as the code in question is s= eldom called


If I find out anything more I will pass it on.


Regards,<= br>David




On Fri, Oct 17, 2008= t 2:25 PM, Rafael Fern=E1ndez L=F3pez <ereslibre@kde.org> :
Hi,


My origonal post has a fix that got around this core dump, ie doing checks<= br> for null pointers.

I know... but my point is that a 'null pointer' should never happen= there (since d is assigned on KFileWidget constructor, and thus, is never = null).

It would be great some context information on the backtrace (like, what KOf= fice code did the call), also it is crucial to know where exactly on the sh= owEvent() the dump happened.

I prefer to understand the problem deeply than adding a null pointer check = blindly that we don't actually understand why is it happening.


Regards,
Rafael Fern=E1ndez L=F3pez.

------=_Part_59728_29326842.1224280179546-- --===============0117651825== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe << --===============0117651825==--