There are many places where SafeString abuses the meaning of ASSERT. A couple of examples:

- AsciiStrToGuid will ASSERT when the length of the passed string is odd
- AsciiStrCatS will ASSERT when the appended string does not fit the buffer

This is absolutely ridiculous and defeats the purpose of these functions. We cannot pass untrusted data to them in DEBUG builds, as they will ASSERT and halt the CPU. This means that the caller must reimplement half of SafeString to be able to use it, which is simply not worth the effort. Clearly the designers missed something here, as ASSERT is an invariant that implies misuse of the function. It is not a way to perform error checking, this is what e.g. function return code is for.

Given how long-standing the problem is and the apparent release of next EDK II stable tag I request this to be addressed in the nearest future.

Disabling ASSERT'ions entirely in SAFE_STRING_CONSTRAINT_CHECK calls may cease some use case of other teams. For this reason we suggest to make an enabled by default compile-time PCD that will enable ASSERTIONS. Sample implementation follows:

#define SAFE_STRING_CONSTRAINT_CHECK(Expression, Status)  \
  do { \
    if (PcdGetBool (PcdAssertOnSafeStringConstraints)) { \
      ASSERT (Expression); \
    } \
    if (!(Expression)) { \
      return Status; \
    } \
  } while (FALSE)

If there are no objections we can submit a patch if necessary, although it may be faster for someone from the core team to make this simple change.