Hello!
I'm currently investigating why a comparison of two PHOTO fields of
different length returns "field equal". PHOTO is defined as:
<field name="PHOTO" type="string" compare="conflict" merge="fillempty"/>
I think the specific situation is that the two values contain a null
byte somewhere in the middle, and the part before that is equal.
I think the following code does the comparison, doesn't it?
sInt16 TStringField::compareWith(TItemField &aItemField, bool aCaseInsensitive)
{
sInt16 result;
PULLFROMPROXY;
if (aItemField.isBasedOn(fty_string)) {
TStringField *sfP = static_cast<TStringField *>(&aItemField);
#ifdef STREAMFIELD_SUPPORT
sfP->pullFromProxy(); // make sure we have all chars
#endif
// direct compare possible, return strcmp
if (aCaseInsensitive)
result=strucmp(fString.c_str(),sfP->fString.c_str());
else
result=strcmp(fString.c_str(),sfP->fString.c_str());
}
...
We have std::string as value and therefore can store null bytes as part
of the data, but the actual comparison falls back to C-string
operations, which only work for null bytes at the end.
I think the strcmp() needs to be replaced with something that also looks
at the rest of the string if no difference is found. Agreed?
Or do we need a real "binary" type? Using string type for PHOTO also has
the risk that during a merge operation, the two values will get
concatenated (thus breaking the images) unless some custom merge script
resolves the conflict differently first.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
_______________________________________________
os-libsynthesis mailing list
[email protected]
http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
