[v1.8.0] flatc prints 0 as default enum value instead of its name

[jvanstraten]

When converting a flatbuffer to json using flatc -t, non-default enum values are represented as their textual name, and default values are not printed. However, when --defaults-json is enabled to also print the default values, they are represented as their numerical value (i.e., 0). That seems unintentional.

To reproduce:

• Make test.fbs:

namespace Test;

enum Color: byte { Red, Green, Blue }

table Test {
  r: Color;
  g: Color;
  b: Color;
}

root_type Test;

• Make test.json:

{
  r: Red,
  g: Green,
  b: Blue
}

• Run flatc -b test.fbs test.json to serialize to test.bin
• Run flatc -t --defaults-json --raw-binary test.fbs -- test.bin to regenerate test.json
• Observe that test.json now contains:

{
  r: 0,
  g: Green,
  b: Blue
}

Note that I'm not expecting flatc to magically remember whether the original json file used names or integers to specify the enum value. I'm just expecting the output format to be consistent.

I'm not familiar with the project sources at all so I have no idea what I'm doing, but the following extremely ugly hack seems to fix this, and doesn't seem to break printing the more complex files I'm working with (Apache Arrow schemas). It doesn't seem worth making a pull request for though, because this certainly cannot be the right way to solve this...

diff --git a/src/idl_gen_text.cpp b/src/idl_gen_text.cpp
index 50d54c5..da2e8c1 100644
--- a/src/idl_gen_text.cpp
+++ b/src/idl_gen_text.cpp
@@ -224,7 +224,7 @@ static bool GenStruct(const StructDef &struct_def, const Table *table,
           (fd.value.type.base_type != BASE_TYPE_STRUCT &&
            fd.value.type.base_type != BASE_TYPE_VECTOR)) text += ":";
       text += " ";
-      if (is_present) {
+      if (is_present || 1) {
         switch (fd.value.type.base_type) {
            #define FLATBUFFERS_TD(ENUM, IDLTYPE, \
              CTYPE, JTYPE, GTYPE, NTYPE, PTYPE) \

It looks like the reason that if is there is because the GenField call beneath it does not correctly look up the default value of a field. So your fix will generate the wrong value if the default isn't 0.

The correct fix is thus to remove the if condition and the else case (like your fix kinda does), but also add a default value lookup to the second GetField call inside GenField. The default value is available in fd.value.constant, but is a string, so needs to correctly be converted to the proper scalar type. We have a StringToInt but no StringToFloat yet.

So yes, a bit messy, which is probably why it wasn't implemented. Wanna have a go at it and make a PR?

[stale]

This issue has been automatically marked as stale because it has not had activity for 1 year. It will be automatically closed if no further activity occurs. To keep it open, simply post a new comment. Maintainers will re-open on new activity. Thank you for your contributions.