Hi Miklos,
you're probably right.
Oliver
On 19.01.2016 16:38, Miklos Vajna wrote:
Hi Oliver,
On Tue, Jan 19, 2016 at 06:39:56AM -0800, Oliver Specht
wrote:
diff --git a/include/LibreOfficeKit/LibreOfficeKit.h
b/include/LibreOfficeKit/LibreOfficeKit.h
index
On 01/19/2016 04:38 PM, Miklos Vajna wrote:
On Tue, Jan 19, 2016 at 06:39:56AM -0800, Oliver Specht
wrote:
diff --git a/include/LibreOfficeKit/LibreOfficeKit.h
b/include/LibreOfficeKit/LibreOfficeKit.h
index 7d4210e..8057d75 100644
---
Hi Oliver,
On Tue, Jan 19, 2016 at 06:39:56AM -0800, Oliver Specht
wrote:
> diff --git a/include/LibreOfficeKit/LibreOfficeKit.h
> b/include/LibreOfficeKit/LibreOfficeKit.h
> index 7d4210e..8057d75 100644
> --- a/include/LibreOfficeKit/LibreOfficeKit.h
> +++
I would just not go down the troubled road of attempting to support
whatever platform-specific file pathname notation in an interface
supposedly designed to take URLs (i.e., stop calling
osl::FileBase::getFileURLFromSystemPath on aURL), and then---if there is
indeed demand to support relative
Hi Stephan,
Stephan Bergmann píše v Po 06. 07. 2015 v 12:06 +0200:
I would just not go down the troubled road of attempting to support
whatever platform-specific file pathname notation in an interface
supposedly designed to take URLs (i.e., stop calling
On 02/20/2013 04:25 PM, julien2412 wrote:
Lubos Lunak wrote
Lubos Lunak wrote
Sorry, I did not realize that = { 0 } actually clears the rest of the
array.
And I do not quite understand why clearing an entire array is supposed to
be
a good way to initialize it when just setting the last one
On Thursday 21 of February 2013, Stephan Bergmann wrote:
FYI: Without having seen this mail thread, I did see the couple of
recent commits to desktop/source/app/officeipcthread.cxx last night, saw
that they still don't address all problems with the sending side not
including NUL bytes at
On Wed, Feb 20, 2013 at 7:54 AM, julien2412 serval2...@yahoo.fr wrote:
Yes I meant it, why? Is it wrong?
if pReceiveBuffer is initialized with 0 for the (sc_nCSASeqLength + 1)
elements thanks to = {0} initialization, what obvious thing did I miss? Why
pReceiveBuffer[nBytes-1] = 0; would need
Norbert Thiebaud wrote
On Wed, Feb 20, 2013 at 7:54 AM, julien2412 lt;
serval2412@
gt; wrote:
Yes I meant it, why? Is it wrong?
if pReceiveBuffer is initialized with 0 for the (sc_nCSASeqLength + 1)
elements thanks to = {0} initialization, what obvious thing did I miss?
Why
On Tuesday 19 of February 2013, Julien Nabet wrote:
desktop/source/app/officeipcthread.cxx |8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
New commits:
commit 7d9a7020eb5777f5baaa8beb6af5db9a8796c7c9
Author: Julien Nabet serval2...@yahoo.fr
Date: Tue Feb 19 21:35:19 2013
Lubos Lunak wrote
On Tuesday 19 of February 2013, Julien Nabet wrote:
diff --git a/desktop/source/app/officeipcthread.cxx
b/desktop/source/app/officeipcthread.cxx index 8db7946..445ccb4 100644
--- a/desktop/source/app/officeipcthread.cxx
+++ b/desktop/source/app/officeipcthread.cxx
@@
Hi all,
I may be completely wrong and I really don't know this code and what it is
aimet to, but I'm worried that
if (nBytes 0)
{
pReceiveBuffer[nBytes-1] = 0;
}
overwrites a received character (that could be '\0' or not).
If I understand correctly, the target is to
On Wed, 20 Feb 2013 15:32:10 +0100
Matteo Casalin matteo.casa...@gmx.com wrote:
Hi all,
I may be completely wrong and I really don't know this code and what it
is aimet to, but I'm worried that
if (nBytes 0)
{
pReceiveBuffer[nBytes-1] = 0;
}
overwrites a
On Wednesday 20 of February 2013, julien2412 [via Document Foundation Mail
Archive] wrote:
Lubos Lunak wrote
On Tuesday 19 of February 2013, Julien Nabet wrote:
diff --git a/desktop/source/app/officeipcthread.cxx
b/desktop/source/app/officeipcthread.cxx index 8db7946..445ccb4 100644
---
Lubos Lunak wrote
Lubos Lunak wrote
Sorry, I did not realize that = { 0 } actually clears the rest of the
array.
And I do not quite understand why clearing an entire array is supposed to
be
a good way to initialize it when just setting the last one to 0 is enough.
...
Why
15 matches
Mail list logo