[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Fix for kfilewidget.cpp
From:       "David Boosalis" <david.boosalis () gmail ! com>
Date:       2008-10-17 21:49:39
Message-ID: 870c99310810171449o56cfc5d1y51af269c26eb693c () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


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 <ereslibre@kde.o=
rg> :

> 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.
>

[Attachment #5 (text/html)]

<div dir="ltr">Rafael.<br>Maybe some one more intimate with kword can address this \
issue.&nbsp; I&#39;ve seen this problem for sometime with koffice in SVN and \
that&#39;s why I peaked a little under the covers to see what it is the matter.&nbsp; \
Eventually they have to address it, or maybe it&#39;s just my system and this is all \
a mute point.<br> <br>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.&nbsp; 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<br> \
<br><br>If I find out anything more I will pass it \
on.<br><br><br>Regards,<br>David<br><br><br><br><br><div class="gmail_quote">On Fri, \
Oct 17, 2008 t 2:25 PM, Rafael Fernández López <span dir="ltr">&lt;<a \
href="mailto:ereslibre@kde.org">ereslibre@kde.org</a>&gt;</span> :<br> <blockquote \
class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt \
0pt 0.8ex; padding-left: 1ex;">Hi,<div class="Ih2E3d"><br> <br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); \
margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> My origonal post has a fix that got \
around this core dump, ie doing checks<br> for null pointers.<br>
</blockquote>
<br></div>
I know... but my point is that a &#39;null pointer&#39; should never happen there \
(since d is assigned on KFileWidget constructor, and thus, is never null).<br> <br>
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 the showEvent() the dump \
happened.<br> <br>
I prefer to understand the problem deeply than adding a null pointer check blindly \
that we don&#39;t actually understand why is it happening.<br> <br>
<br>
Regards,<br><font color="#888888">
Rafael Fernández López.<br>
</font></blockquote></div><br></div>



>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<


[prev in list] [next in list] [prev in thread] [next in thread]