search

Podger2016 / rapidjson

Automatically exported from code.google.com/p/rapidjson
0 stars 0 forks source link

PrettyPrint should handle null node #80

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
What steps will reproduce the problem?

TEST(PrettyWriterTest, null)
{
    Document doc;
    StringBuffer out;
    PrettyWriter<StringBuffer> writer(out);
    doc.Accept(writer);
    EXPECT_STREQ("null", out.GetString());
}

What is the expected output? What do you see instead?

Proposed unit test indicates the expected behavior.  Instead, the assert on 
line 146 of prettywriter.h triggers:

RAPIDJSON_ASSERT(type == kObjectType || type == kArrayType);

What version of the product are you using? On what operating system?

v0.11 on CentOS 6.1 (GCC 4.4.5)

Please provide any additional information below.

I believe an appropriate fix is to change the assert to the following:

RAPIDJSON_ASSERT(type == kObjectType || type == kArrayType || type == 
kNullType);

Original issue reported on code.google.com by Matthew....@gmail.com on 17 Jun 2013 at 10:28

GoogleCodeExporter commented 8 years ago 
According to http://www.ietf.org/rfc/rfc4627.txt

2.
      "A JSON text is a serialized object or array."

null is not a valid JSON text.

But you may change your own code to suit your need.

Original comment by milo...@gmail.com on 18 Jun 2013 at 1:34

GoogleCodeExporter commented 8 years ago 
It would appear that the goal of PrettyWriter is to produce valid JSON text.

It would appear that the goal of Document is to represent valid JSON text as a 
DOM-like object.

However, a default-constructed Document is NOT a representation of valid JSON 
text.  This is a surprising characteristic.

Perhaps some documentation could be added somewhere indicating that this 
dissonance is intentional.

Original comment by Matthew....@gmail.com on 18 Jun 2013 at 2:21

GoogleCodeExporter commented 8 years ago 
The document may not state clearly that a default constructed document is in 
invalid state (null).

Currently it would need to explicitly call SetArray() or SetObject() for 
Docuemnt to be a valid document.

I will consider to change this default behavior.

Original comment by milo...@gmail.com on 18 Jun 2013 at 2:29

GoogleCodeExporter commented 8 years ago

Original comment by milo...@gmail.com on 18 Jun 2013 at 2:29

GoogleCodeExporter commented 8 years ago 
Fixed in https://github.com/miloyip/rapidjson/pull/101

Original comment by milo...@gmail.com on 11 Aug 2014 at 4:30