Recent changes to bugs

Exception specifications cause process termination

Stephen Lynch — Fri, 05 Oct 2012 11:04:17 -0000

The exception specifications in jaula cause process termination when new throws std::bad_alloc exceptions even if the exeption could have been caught and handled successfully.

The general advice I've seen regarding exception specs. is to remove them (eg. http://www.gotw.ca/publications/mill22.htm ) so that's what I've done.

Patch attached

Object names are not escaped

Stephen Lynch — Fri, 05 Oct 2012 10:52:00 -0000

if you have the object described by the following JSON
{ "\"key\" ": "\"value\"" }
Stored in memory jaula will serialise that as
{ ""key"": "\"value\"" }

according to http://www.json.org/ the object name should be treated the same was as a value string.

(inefficient) patch attached.

asString() on intValue throws exception

sorenriise — Sat, 26 Jun 2010 23:43:11 -0000

I had expected just about everything should be able to retrieve as String -- including objects and arrays (feature suggestion).

reader.parse("{\"intvalue\":1}",root);
if (root["intvalue"].isConvertibleTo(Json::stringValue)) // isConvertibleTo is returning true
cout << root["intvalue"].asString() // throws exception......

jaula and opencv

Anonymous — Tue, 08 Jun 2010 18:38:29 -0000

Hi! I'm creating some opencv app and decided to use JSON to pass some objects inside my system. And here problem begans.
I process a picture inside one thread, get some data from it - then serialize it to JSON strings. As a veryfication I want to recover objects from those strings and compare them. Then problem occurs - parser aborts when it meets a float inside the table. It says "non-numerical value <here comes the float> not enclosed in double quotes". But here it is fun part - when I comment imshow() line, which I use to have preview on the processed file, problem vanishes and parsing continues without any problems. Any clues what could cause this error??
Best Regards
Konrad

Multi-byte symbolse are incorrectly encoded to utf8

Anonymous — Thu, 25 Feb 2010 16:53:36 -0000

Value_String::stringRepr() function doesnt encode multi-byte UTF8 symbols correctly.
For example the symbol ∛ - should be output as \u8731 but is output as \u00e2\u0088\u009b

Library version - 1.4.0

gcc-4.4 missing include

Loic Dachary — Wed, 29 Apr 2009 21:46:22 -0000

You always have to #include headers directly and cannot
rely for things to be included indirectly.

You can reproduce this problem with gcc-snapshot from unstable or
gcc-4.4 from experimental.

> > Automatic build of jaula_1.4.0-2 on em64t by sbuild/amd64 0.53
...
> > libtool: compile: x86_64-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I.. -g -O2 -MT jaula_lexan.lo -MD -MP -MF .deps/jaula_lexan.Tpo -c jaula_lexan.cc -fPIC -DPIC -o .libs/jaula_lexan.o
> > jaula_lexan.cc: In member function 'int jaulaFlexLexer::yyinput()':
> > jaula_lexan.cc:1505: error: 'EOF' was not declared in this scope
> > make[4]: *** [jaula_lexan.lo] Error 1
> > make[4]: Leaving directory `/build/tbm/jaula-1.4.0/jaula'

The patch below will work. However, since the other #include
statements are wrapped in an #ifdef statement you may want to do this
for this #include too.

--- jaula/jaula_lexan.ll~ 2009-04-29 20:55:20.000000000 +0000
+++ jaula/jaula_lexan.ll 2009-04-29 20:56:24.000000000 +0000
@@ -50,6 +50,8 @@
#endif
}

+#include <cstdio>
+
#ifdef HAVE_SSTREAM
#include <sstream>
#endif

Please do not provide jaula/jaula_lexan.cc in tarball

Artur R. Czechowski — Wed, 02 Jul 2008 00:13:43 -0000

If you provide this file in tarball make does not run flex to regenerate it. So, we have .cc file generated by your version of flex and during compilation we using FlexLexer.h from our version of flex. It leads to some strange compilation error. This error just disappeared after I deleted jaula/jaula_lexan.cc and flex regenerated it on its own.

False Value - Type in Value_Object - Constructor

Anonymous — Thu, 15 Nov 2007 09:33:07 -0000

In the implementation of Value_Object there is an error concerning the assignment of the objects value type to the base constructor Value_Complex. Must be "TYPE_OBJECT", not "TYPE_ARRAY". This error leads to problems in resolving the type of a value when receiving a JSON - Message.

AM_CPPFLAGS assumes gcc

Corey Stup — Tue, 06 Nov 2007 21:26:10 -0000

In Makefile.in:
AM_CPPFLAGS = -Wall

-Wall only works on gcc compilers. ./configure will use other compilers (via CC and CCC), but the Makefiles must be hand edited.

Problem processing escaped text

Anonymous — Fri, 04 May 2007 12:45:30 -0000

jparse crashes processing the attached example it works when the backslash is removed.