Bug 2904

Summary: The HTML report generator cannot handle uint8_t
Product: ns-3 Reporter: Jörg Christian Kirchhof <christian.kirchhof>
Component: test frameworkAssignee: ns-bugs <ns-bugs>
Status: PATCH WANTED ---    
Severity: normal CC: tomh
Priority: P3    
Version: ns-3.28   
Hardware: All   
OS: All   
See Also: https://www.nsnam.org/bugzilla/show_bug.cgi?id=2916

Description Jörg Christian Kirchhof 2018-03-29 10:44:39 EDT
Overview:
The compiler treats uint8_t as char for printing. For uint8_t this not only does not make sense, but also causes a crash of test.py when it is supposed to generate an HTML report, as it cannot handle control characters.

Steps to Reproduce: 
1) Create a test suite / case that compares two uint8_t's. Example:
      uint8_t a = 3;
      uint8_t b = 5;
      NS_TEST_ASSERT_MSG_EQ (a, b, "This should fail.");
2) Run test.py for the newly created test-suite with the option to create an HTML report.


Actual Results: 
test.py crashes in  translate_to_html.

Expected Results: 
The test framework should detect the uint8_t and treat it as a number. A report should be created as usual.

Build Date & Hardware: 
ns-3.28 on Mac OS X High Sierra.

Additional Information: 
The reason for this is that uint8_t gets treated as a char when printing. std::to_string can solve this. However, simply adding std::to_string to the macro would not work since std::to_string does not accept strings as input. Maybe the NS_TEST_ASSERT_MSG_EQ and other macros can be replaced by function templates? Alternatively, this could be fixed by writing the actual number to the results.xml instead of treating uint8_t as a character there. 

As a workaround, the user can cast every uint8_t he gives to the macros to uint16_t. Even if this issue will not be fixed, the need of casting uint8_t variables should be documented.
Comment 1 Tom Henderson 2018-03-30 10:21:14 EDT
> The reason for this is that uint8_t gets treated as a char when printing.
> std::to_string can solve this. However, simply adding std::to_string to the
> macro would not work since std::to_string does not accept strings as input.
> Maybe the NS_TEST_ASSERT_MSG_EQ and other macros can be replaced by function
> templates? Alternatively, this could be fixed by writing the actual number
> to the results.xml instead of treating uint8_t as a character there. 
> 
> As a workaround, the user can cast every uint8_t he gives to the macros to
> uint16_t. Even if this issue will not be fixed, the need of casting uint8_t
> variables should be documented.

-1 for casting inputs to these macros; we were able to avoid this with NS_LOG with this type of solution:

http://code.nsnam.org/ns-3-dev/diff/b34ee29ed6ab/src/core/model/log.cc

Some kind of solution like this would be preferred (Method E):
https://bytefreaks.net/programming-2/c/c-how-to-print-an-unsigned-character-unsigned-byte-uint8_t-using-cout