Usually, reports have the form of XML with the report name as top-level node type. So in this common case, the report consumer may check for this condition, e.g., to see if a pointer report as issued by nitpicker is valid, one may do:
if (_config.xml().type() == "pointer") ...
If nitpicker closes the report session, report_rom will clear the dataspace. So the dataspace will start with a 0 instead of the top-level XML node. In this case, the 'Attached_rom_dataspace` returns the '<empty/>' node. In the hypothetical case that a valid report is called "empty", one could still check whether the dataspace contains a null-termination at the beginning:
if (_config.local_addr<char const>()[0]) ...
In short, it is already possible to distingish both cases, isn't it?
Thanks for the clarification, Norman. I wasn't aware that the 'Attached_rom_dataspace' automagically returns the '<empty/>' node. Works for me ;-)
Or to put it another way: Initially, i.e. if no report session was created (yet), the report_rom delivers an invalid dataspace to the ROM clients. Shouldn't the report_rom restore this state after the report session was closed?
You raise a good point. But instead of confronting the ROM client with an invalid dataspace (which most ROM clients do not anticipate and therefore don't handle), I would rather deliver a zeroed dataspace initially to achieve the desired consistency. Thanks for pointing out this current deficiency!
Perfect.