int64 serialization/deserialization not working properly

[paralin]

var protobufjs = require('protobufjs');
var ro = protobufjs.loadSync('./test.proto');

var test = ro.lookup('test.Test');
var enc = test.encode({int_64: '314159265358979'}).finish();
var dec = test.decode(enc);

if (dec.int_64 === '314159265358979') {
  console.log('Test passed.');
} else {
  console.log(dec.int_64 + ' != 314159265358979 (expected)');
}

syntax = "proto3";
package test;

message Test {
  fixed64 int_64 = 1;
}

Output:

16675180715352071609 != 314159265358979 (expected)

Extracted from a failing test case in grpc. long is not installed. Node v6.9.1

[dcodeIO]

var enc = test.encode({int_64: 314159265358979}).finish(); // not a string

Still wondering where the other number comes from.

[paralin]

Yeah maybe, but these guys at grpc seem to want to pass it in as a string. For backwards compat would it be possible to accept this and convert it in Protobuf.JS?

[dcodeIO]

Will see what I can do, need to setup this test first!

[dcodeIO]

Alright, most of this should be working now. Without a long-lib, parseInt is used for strings now.

However, I doubt that the following line

if (dec.int_64 === '314159265358979') {

would actually work with v5, because v5 always returns a Long instance when fixed64 is supported. Hence, I assume that grpc is using long actually (if it has protobufjs in its dependencies, it even must because it is a non-optional dep on node prior to v6).

What actually works with a long lib is this:

if (dec.int_64 == '314159265358979') {

because there is Long#toString, which is called implicitly here (at the cost of some usually unnecessary overhead btw - converting hence and forth between longs and strings is suboptimal).

Test case

Let me know if this is sufficient!

[paralin]

I'm testing it still and it doesn't seem to want to work properly, I have long installed as a dependency. Investigating some more.

[paralin]

Okay, two of the test cases are fixed, see #536 for the next issue :)