aboutsummaryrefslogtreecommitdiffstats
path: root/lib/diameter
diff options
context:
space:
mode:
authorNico Kruber <[email protected]>2012-04-25 10:32:07 +0200
committerNico Kruber <[email protected]>2012-06-13 18:05:59 +0200
commita963b819552657d9df0ffae7ee9d9143a5b319e5 (patch)
tree551e5997f108491d010a09e50a76aa34bed43ab3 /lib/diameter
parent628d51fd2171cb6e8275f9a16d85300e42e83594 (diff)
downloadotp-a963b819552657d9df0ffae7ee9d9143a5b319e5.tar.gz
otp-a963b819552657d9df0ffae7ee9d9143a5b319e5.tar.bz2
otp-a963b819552657d9df0ffae7ee9d9143a5b319e5.zip
fix reading compressed binary terms from Java
Larger compressed binary could not be decoded inside JInterface. - applied a patch posted on erlang-questins in September 2009 http://erlang.org/pipermail/erlang-patches/2009-September/000478.html -> extended this patch as it alone was not enough to fix the bug Problem was that when reading from an InputStream, you can only specify a maximum number of bytes to read. Java doesn't quarantee that it actually reads this many bytes - it could be less! This patch now reads up until the expected size bytes. If there are more than expected, the actual number of available bytes is not printed (we probably shouldn't read the additional bytes, security-wise - the erlang external byte representation is broken in this case though).
Diffstat (limited to 'lib/diameter')
0 files changed, 0 insertions, 0 deletions