Define StrCmp in a funky was to be bug-compatible with EDK2 code.

Paper over a coverity issue:

*** CID 1372592:  API usage errors  (BAD_COMPARE)
/lib/libefivar/efivar-dp-parse.c: 2723 in DevPathFromTextiSCSI()
   Truncating the result of "strcmp" to "unsigned short" may cause it
   to be misinterpreted as 0. Note that "strcmp" may return an integer
   besides -1, 0, or 1.

We do this by making StrCmp return either 0 or 1 for equal or
not-equal.  There's a bug in the DevPathFromTextiSCSI cast of the
return value and this workaround will fix it without breaking other
users of StrCmp (all of which test for == 0).

https://bugzilla.tianocore.org/show_bug.cgi?id=440 has been filed
upstream to log this issue.

CID: 1372592
Sponsored by: Netflix

lib/libefivar/uefi-dplib.h

@@ -508,7 +508,16 @@ UefiDevicePathLibConvertTextToDevicePath (
 #define LShiftU64(x, s) ((x) << s)
 #define ReadUnaligned64(x)    le64dec(x)
 #define ReallocatePool(old, new, ptr) realloc(ptr, new)
-#define StrCmp(a, b) strcmp(a, b)
+/*
+ * Quirky StrCmp returns 0 if equal, 1 if not. This is what the code
+ * expects, though that expectation is likely a bug (it casts the
+ * return value. EDK2's StrCmp returns values just like C's strcmp,
+ * but the parse code casts this to an UINTN, which is bogus. This
+ * definition papers over that bogusness to do the right thing.  If
+ * iSCSI protocol string processing is ever fixed, we can remove this
+ * bletcherous kludge.
+ */
+#define StrCmp(a, b) (strcmp(a, b) != 0)
 #define StrCpyS(d, l, s) strcpy(d, s)
 #define StrHexToUint64(x) strtoll(x, NULL, 16)
 #define StrHexToUintn(x) strtoll(x, NULL, 16)