On Tue, 18 Jan 2011 07:45:04 -0700, "Tor Lillqvist"
wrote:
>>> Or am I missing something...
>> Yes, we have a miserable trap of fall-through:
>
> No, I did see the fall-through. But if pDlg is NULL (a bit earlier), we don't
> enter the block that contains the switch with the fall-through, wher
On Tue, 2011-01-18 at 07:45 -0700, Tor Lillqvist wrote:
> >> Or am I missing something...
> > Yes, we have a miserable trap of fall-through:
>
> No, I did see the fall-through. But if pDlg is NULL (a bit earlier), we
> don't enter the block that contains the switch with the fall-through,
> wher
>> Or am I missing something...
> Yes, we have a miserable trap of fall-through:
No, I did see the fall-through. But if pDlg is NULL (a bit earlier), we don't
enter the block that contains the switch with the fall-through, where the other
(hopefully only other possible) case does set pArgs.
--
Hello,
So, in that patch, remove also the German comment that says something
similar in different words.
Cheers
F.
On Tue, 2011-01-18 at 23:27 +0900, Takeshi Abe wrote:
> On Tue, 18 Jan 2011 03:26:14 -0700, "Tor Lillqvist"
> wrote:
> > Ah OK. I see that now when I pulled a fresher version.
>
On Tue, 18 Jan 2011 03:26:14 -0700, "Tor Lillqvist"
wrote:
> Ah OK. I see that now when I pulled a fresher version.
>
> But unless I am mistaken, now then pArgs might in theory be de-references
> while NULL?
>
> Consider this code path:
>
> const SfxItemSet* pArgs = rReq.GetArgs();
>
>
> Caolán has fixed the code around in a way to ensure pPV always initialized.
Ah OK. I see that now when I pulled a fresher version.
But unless I am mistaken, now then pArgs might in theory be de-references while
NULL?
Consider this code path:
const SfxItemSet* pArgs = rReq.GetArgs();
Hi Tor,
Thanks for your reply.
On Tue, 18 Jan 2011 01:49:01 -0700, "Tor Lillqvist"
wrote:
> Thanks for the patch. The code in that method,
> sd/source/ui/func/fusnapln.cxx: FuSnapLine::DoExecute( SfxRequest& rReq ), is
> indeed interesting. In theory there are code paths through it that lead
Thanks for the patch. The code in that method, sd/source/ui/func/fusnapln.cxx:
FuSnapLine::DoExecute( SfxRequest& rReq ), is indeed interesting. In theory
there are code paths through it that lead to a NULL pPV (and pArgs) pointer
de-references, as cppcheck correctly notices. (But clearly, assu
Hi,
cppcheck said that
> [impress/sd/source/ui/func/fusnapln.cxx:186]: (error) Possible null pointer
> dereference: pPV
which is, at a glance, worth noting.
It would be great if someone shows the de-referenceing has no problem,
otherwise the attached patch may provides a workaround.
Cheers,
-- T
