suppress clang undefined behavior sanitizer in ImfAttribute<T>::copyValuesFrom()

[cary-ilm]

Addresses https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=23996

If an input file contains an invalid value for DeepImageState, clang will generate an Invalid-enum-value warning. The proper behavior is to carry the invalid value, so it will be preserved on file write. This could potentially happen with "legal" files if the DeepImageState enum were ever extended in the future, in which case old versions of the library should read the new files.

Suppressing the warning in this one case is preferable to disabling all undefined behavior by the sanitizer, because other instances of undefined behavior may be legitimate bugs.

Signed-off-by: Cary Phillips cary@ilm.com

[meshula]

same comment as per #780

[cary-ilm]

Revisiting this after some consideration. @peterhillman, is the proper solution to avoid assigning the invalid DeepImageState enum value as you did in #785, or allow the invalid value and shut the sanitizer up, as this change does? I don't believe that invalid DeepImageState values are caught by sanityCheck(). Is that intentional or an oversight?

[peterhillman]

@cary-ilm Looking specifically at enums which could be "invalid" in a file: Compression, LineOrder, PixelType and TileDescription are all enums which influence the data in the file. Unknown values make the file unreadable and sanityCheck should catch them. It makes sense to catch them in readValueFrom too, before they are cast to enum, to avoid undefined behavior.
DeepImageState and EnvMap have no effect on reading data from the file, and could potentially be extended in the future. It would be nice to allow future values through, which means sanityCheck should not catch them, though that does require them to be validated when they are used.

[cary-ilm]

Closing this in favor of #794, a better solution.