VUnit outputs illegal characters(0x0) in XML

[davidmedinasigasi]

Running python run.py -x test_report.xml in json4vhdl generates an XML that contains 0x0 in the <system-out> tag. However, most control characters under 0x20 are not allowed in XML.

[std-max]

I think the problem is due to the print of the content of the JSON object. This content contains a lot of NUL characters. https://github.com/VUnit/vunit/blob/c23790d8159e0ced8cd8ffd00c50d6d2c5425e3d/examples/vhdl/json4vhdl/src/test/tb_json_gens.vhd#L29 In the example, we should use the trim function like this:

info("JSONContent: " & lf & JSON.json.jsonTrim(JSONContent.Content));

With that change, there is no invalid characters in the XML file.

However, that does not solve the problem in general. If a user prints invalid XML characters in VHDL, I think we should not prevent that action at the VHDL level but rather sanitize when the XML file is created with Python.

But ESCAPE character is invalid in XML, so what should we do when the log contains ANSI color escape sequences? @umarcor @LarsAsplund

[std-max]

@eine maybe you have an idea to solve this?

[umarcor]

@std-max, using the trim function in the json4vhdl example sounds as a good solution to me. Will you please propose a PR?

However, that does not solve the problem in general. If a user prints invalid XML characters in VHDL, I think we should not prevent that action at the VHDL level but rather sanitize when the XML file is created with Python.

But ESCAPE character is invalid in XML, so what should we do when the log contains ANSI color escape sequences?

I believe that a sane solution would be to split out the conflictive logs. So, I agree with you it should be done in Python, at the time the XML file is generated. However, rather than trying to transform or trim the content, we should just put it in a .log file and have a relative path in the XML field. That would imply generating a tarball instead of just a file. Nevertheless, it should be straightforward for any tool processing the XML to get the full log if desired.

/cc @Paebbels

[std-max]

@umarcor I will propose a PR this afternoon for the erroneous example.

I like the solution you proposed with a separate log file. Maybe I (or you if you have time) should file a new issue to propose the solution and see what @LarsAsplund and others think about it ?