Add DXM_NO_SAL define switch to disable SAL

[sbd1138]

A less intrusive way to disable SAL (remove sal.h dependency and conflicting definitions) in DirectXMath. Defining DXM_NO_SAL before including DirectXMath.h will enable this. It also detects if sal.h has already been included elsewhere and acts appropriately. The argument could be made that instead of an external switch we should do this for all non-Microsoft compilers (effectively, #ifndef _MSC_VER instead of #ifdef DXM_NO_SAL), but the extra control seemed useful.

[sbd1138]

Was mulling this over the past week and thought of a less intrusive way to get around the sal.h issue that didn't involve altering the SAL annotations everywhere. What do you think?

[walbourn]

Any local defining of SAL macros tends to cause problem with our tools. The open source sal.h is the least intrusive solution for my GCC scenarios including WSL.

An easy solution for your is to just create a sal.h in your include path that defines:

#define _In_
#define _In_reads_(size)
#define _In_reads_bytes_(size)
#define _Out_
#define _Out_opt_
#define _Out_writes_(size)
#define _Out_writes_bytes_(size)
#define _Use_decl_annotations_
#define _Analysis_assume_(expr)
#define _Success_(expr)

As long as you aren't defining the legacy SAL v1 defines, it shouldn't conflict with GCC. No changes required.

[sbd1138]

Thanks for taking a look Chuck. Ultimately, my goal was to remove the three-fold hassle of having to scare up the open source SAL, and then alter include paths for GCC to it, and then obviously deal with the GCC std lib includes issue. Just trying to make DirectXMath drop-in for GCC, so-to-speak. Per your suggestion, would creating a dxm_no_sal.h that contains the defines and referencing that instead of doing the inlines directly in DirectXMath.h conform better? Meaning a new header directly provided by the DirectXMath package. Or would that still run afoul of MSFT tools by its mere inclusion in the package proper?