Error messages containing PVL keyword names may not contain the correct name
PvlKeyword::operator has an error message that passes the m_name variable (of type char*) into a toString() method.
There is no implementation for toString(char*) so this call is being interpreted as toString(bool) and always returning the string "Yes" as the keyword name. Since the compiler sees the char* as equivalent to bool, implementing an overloaded toString(char*) method may cause a conflict.
This use of the toString(bool) method causes a confusing error message for the user when the index passed into PvlKeyword::operator goes out of bounds. As a temporary fix, I have changed the error message to use the QString(char*) constructor instead of toString().
#3 Updated by Stuart Sides almost 4 years ago
- Subject changed from We do not have a method to convert char* to a QString (in IString) to Error messages containing PVL keyword names may not contain the correct name
The conversion from a char* to a string is using the toString(bool). This produces a "Yes" when it should produce the keyword name. Add a member to iString to with the correct signuture for char*
#21 Updated by Adam Goins 3 months ago
- Status changed from In Progress to Resolved
- Impact updated (diff)
Jeannie's quickfix to wrap the m_name (of type char*) in a QString constructor does make the Pvl error message display the correct keyword.
Seeing how we don't use IString anymore and have migrated to QString, would that make Jeannie's initial quickfix a viable fix for this ticket?
The documentation for PvlKeyword::operator reflected the return being an IString still, it was changed to reflect a QString appropriately.
I've added a unitTest in PvlKeyword to check the IndexOutOfBoundsException and display the error message shown, and it does correctly display the keyword name in the error message.
This output was written to PvlKeyword.truth (as the only new truthdata is an additional line of output that displayed the correct error message with the correct keyword name).
These changes can be found in the work area under /work/project/isis/latest/m02084.
#24 Updated by Adam Goins 29 days ago
- Status changed from Resolved to Acknowledged
- Assignee deleted (
- Impact updated (diff)
The issue here is caused by ambiguous overloading.
The issue is that we don't have a IString::toString(char*) method, so when we pass in a string, such as toString("Hey!"), it will compile to the IString(bool) method instead.
c++ compilers will always interpret a char* as a boolean, so even if we implement an overloaded toString(char*) method it will still always output the toString(bool) method instead.
The 'explicit' keyword doesn't apply to toString because it's not a constructor, and making these values consts yields no positive results either.