Where did the serialized data come from?
What library are you using on Android?
Do you have test code that runs on Android that exhibits the problem?
-- Wink
On Mon, Jun 14, 2010 at 11:34 PM, Rashmi rashmi.malav...@gmail.com wrote:
message info
{
required string username
1. I run it under valgrind. It shows unconditional jump on the line
that is calling has_is_valid(), and if I remove that if() block,
there is no memcheck or leakcheck problems at all.
I have to mention that: a) the messages that I am trying to parse are
generated by apps that are using an older
what I meant about unconditional jump was in fact Conditional jump
or move depends on uninitialised value(s) message.
--
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to this group, send email to proto...@googlegroups.com.
To
I suspect that somewhere in your pipeline, the data is being interpreted as
a C-style NUL-terminated string and thus being truncated at the first
zero-value byte.
On Wed, Jun 16, 2010 at 2:20 PM, DFlo dflo...@raptr.com wrote:
Keeping this as short as possible, I'm using protobuf to communicate
Entirely possible, but given that the expected number of bytes arrive
on the read-end of the pipe and get accumulated into a buffer, the
problem for this particular case would seem to occur within
ParseFromString/MergeFromString. I'm not aware of zero-valued bytes
causing problems in any other
Wow, don't I feel like an idiot ... on the sending side, strncpy !=
memcpy.
Even though I allocated a big enough buffer, I didn't copy everything
into it.
I think I've embarrassed myself sufficiently for one day...
hang-dog_expression /
As you were
DFlo
On Jun 16, 4:35 pm, DFlo
Status: New
Owner: ken...@google.com
Labels: Type-Defect Priority-Medium
New issue 198 by sri...@malhar.net: Unnecessarily inefficient calculation
of utf-8 encoded lengt
http://code.google.com/p/protobuf/issues/detail?id=198
Version: 2.3.0
File: CodedOutputStream.java
public static int
Updates:
Status: Fixed
Labels: FixedIn-2.3.1
Comment #1 on issue 198 by ken...@google.com: Unnecessarily inefficient
calculation of utf-8 encoded lengt
http://code.google.com/p/protobuf/issues/detail?id=198
Unfortunately your code is incorrect in the case of code points