On Wednesday 20 of February 2013, julien2412 [via Document Foundation Mail
<br/>Archive] wrote:
<div class='shrinkable-quote'><br/>> Lubos Lunak wrote
<br/>>
<br/>> > On Tuesday 19 of February 2013, Julien Nabet wrote:
<br/>> >> diff --git a/desktop/source/app/officeipcthread.cxx
<br/>> >> b/desktop/source/app/officeipcthread.cxx index 8db7946..445ccb4 100644
<br/>> >> --- a/desktop/source/app/officeipcthread.cxx
<br/>> >> +++ b/desktop/source/app/officeipcthread.cxx
<br/>> >> @@ -497,23 +497,17 @@ OfficeIPCThread::Status
<br/>> >> OfficeIPCThread::EnableOfficeIPCThread() else if(
<br/>> >> pThread->maPipe.create( aPipeIdent.getStr(), osl_Pipe_OPEN, rSecurity ))
<br/>> >> // Creation not successfull, now we try to connect {
<br/>> >> osl::StreamPipe aStreamPipe(pThread->maPipe.getHandle());
<br/>> >> - char pReceiveBuffer[sc_nCSASeqLength + 1];
<br/>> >> + char pReceiveBuffer[sc_nCSASeqLength + 1] = {0};
<br/>> >> int nResult = 0;
<br/>> >> int nBytes = 0;
<br/>> >> int nBufSz = sc_nCSASeqLength + 1;
<br/>> >> // read byte per byte
<br/>> >> - pReceiveBuffer[0] = 0;
<br/>> >> while ((nResult=aStreamPipe.recv( pReceiveBuffer+nBytes,
<br/>> >> nBufSz-nBytes))>0) { nBytes += nResult;
<br/>> >> if (pReceiveBuffer[nBytes-1]=='\0') {
<br/>> >> break;
<br/>> >> }
<br/>> >> }
<br/>> >> - /* make sure the buffer is \0 terminated */
<br/>> >> - if (nBytes > 0)
<br/>> >> - {
<br/>> >> - pReceiveBuffer[nBytes-1] = 0;
<br/>> >> - }
<br/>> >
<br/>> > Did you really mean to remove this part?
<br/>>
<br/>> Hi Lubos,
<br/>>
<br/>> Yes I meant it, why? Is it wrong?
<br/>> if "pReceiveBuffer" is initialized with 0 for the (sc_nCSASeqLength + 1)
<br/>> elements thanks to = {0} initialization, what obvious thing did I miss?
</div><br/> Sorry, I did not realize that = { 0 } actually clears the rest of the array.
<br/>And I do not quite understand why clearing an entire array is supposed to be
<br/>a good way to initialize it when just setting the last one to 0 is enough.
<br/><br/>> Why "pReceiveBuffer[nBytes-1] = 0;" would need to stay?
<br/><br/> If I'm reading the code correctly, "nBytes-1" is not the position after the
<br/>read data, but the last read item. Which should mean that the repeated recv()
<br/>may rewrite all the 0's from the initialization. That rather begs the
<br/>question why it changes the last read item instead of terminating it, so the
<br/>code may have been already broken to begin with.
<br/><br/>--
<br/> Lubos Lunak
<br/> <a href="/user/SendEmail.jtp?type=node&node=4038899&i=0" target="_top" rel="nofollow" link="external">[hidden email]</a>
<br/>
<br/><hr align="left" width="300" />
View this message in context: <a href="http://nabble.documentfoundation.org/Re-Libreoffice-commits-core-git-desktop-source-tp4038892p4038899.html">Re: [Libreoffice-commits] core.git: desktop/source</a><br/>
Sent from the <a href="http://nabble.documentfoundation.org/Dev-f1639786.html">Dev mailing list archive</a> at Nabble.com.<br/>