On Wed, 28 Feb 2024, LIU Hao wrote:

Attached is the updated patch.

Ok, so let's see...

because the semicolon in the macro `lstrcpyA` affects not only invocations, but also declarations. Those semicolons have been removed since Windows SDK 8.0, so we remove them as well. This allows including 'strsafe.h' before 'windows.h'.

Right, so this is the main fix of the patch - remove semicolons, which avoids breaking winnt.h if strsafe.h is included before that.

There is an unsolved issue about `DEPRECATE_SUPPORTED`: It's a macro that is to be defined by 'winnt.h', so the order of inclusion matters:

All the talk about DEPRECATE_SUPPORTED is almost indecipherable in this commit message, if one just looks at our headers and/or this patch - only after looking at the WinSDK headers, I see what you're saying.

It would be much more understandable, if the message would start with some context like this:

---8<---

WinSDK's strsafe.h also tries to discourage users from calling a bunch of its internal functions. This is done in two different ways; if DEPRECATE_SUPPORTED is defined (it gets defined by winnt.h), the functions are marked deprecated via e.g. "#pragma deprecated(StringLengthWorkerA)". If that isn't defined, those symbols are redefined to a missing name instead, e.g. "#define StringLengthWorkerA StringLengthWorkerA_instead_use_StringCchLengthA_or_StringCbLengthA"

As GCC doesn't support #pragma deprecated, our version doesn't use that, so we only redirect/rename uses of these functions if DEPRECATE_SUPPORTED isn't defined - to match the effect on the WinSDK headers (where the names are usable but gets warned about, if DEPRECATE_SUPPORTED is defined).

---8<---

That, IMO, is more understandable by people just looking at the patch in isolation, and/or looking at our headers.

Alternatively, we could just skip adding this ifdef in this patch, as we don't have the alternative way of marking the deprecation - that would get the message across to the users even more clearly?

// Martin



_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Reply via email to