Closed jimsch closed 5 years ago
As the documentation for CBORObject#ToString()
says: "The format is intended to be human-readable, not machine-readable, the format is not intended to be parsed, and the format may change at any time." It is not appropriate for an application to rely on ToString()
for its correctness. Instead, you should call .Equals(CBORObject.True)
or CBORObject#IsTrue
or .Untag().Equals(CBORObject.True)
, whichever is appropriate for the application, to determine whether a CBOR object holds the simple value True.
However, I agree "21" is an unintuitive string value for CBORObject.True
and may have been so by accident. I will investigate.
I am not doing the comparison in my program, but rather in the output. I don't have any problems with doing updates of that string over time as things change, but this is not going to promote uses to understand things. This string is dumped as part of examples for people in the COSE test suite. Reading this is easier than reading a hex string.
Released version 4.0.1 which dealt with this issue. However, note that for now, a more stable solution is to write your own method that converts CBOR objects to strings. You can use the current implementation given in CBORObject.ToString()
as a guide. (Note that for stable results, map keys need to be sorted, which ToString()
currently does not do.)
string x = CBORObject.True.ToString();
results in "21" not in "true"
I just upgraded due to the security issue and am having this problem when doing comparisons on strings produced. The output of "{1:21}" is really not the same as "{1:true}"