GCC9 break: trying to memcpy C++ objects

[ns-osmolsky]

GCC9 identifies a case of undefined behavior where the code attempts to copy C++ objects with std::memcpy.

rapidjson/include/rapidjson/document.h:1939:24: error: ‘void* memcpy(void*, const void*, size_t)’ writing to an object of type ‘class NsJson::GenericValue<NsJson::UTF8<> >’ with no trivial copy-assignment; use copy-assignment or copy-initialization instead [-Werror=class-memaccess]

[2020-04-22T03:02:10.929Z]  1939 |             std::memcpy(e, values, count * sizeof(GenericValue));
[2020-04-22T03:02:10.929Z]       |             ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

rapidjson/include/rapidjson/document.h:540:7: note: ‘class NsJson::GenericValue<NsJson::UTF8<> >’ declared here
[2020-04-22T03:02:10.929Z]   540 | class GenericValue {
[2020-04-22T03:02:10.929Z]       |       ^~~~~~~~~~~~

[miloyip]

This is a warning. I suggest adding pragma to ignore this.
Other suggestions are welcome.

[ns-osmolsky]

I suggest that you fix the broken code by merging #1698.

[jcbollinger]

It is perilous to ignore or suppress warnings about undefined behavior. Exercising UB is a primary source of misbehavior, and especially for optimization-associated behavior variation. And it is especially an issue for a header-only library such as this one, because it is impossible for the library distribution to provide suitable tests for the observable behavior, as it may vary from use to use.

This issue (which also affects GCC 8) ought to be fixed, not papered over.

[ns-osmolsky]

@jcbollinger indeed, see #1698.

[RaoGuangxiang]

git clone the latest, inteading of downloading in the release url.