On Thu, 29 Feb 2024, LIU Hao wrote:
在 2024-02-29 01:14, Martin Storsjö 写道:
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"
This contradicts my understanding:
I don't think that `DEPRECATE_SUPPORTED` is a macro that is to be defined by
users. Its conditional definition in 'winnt.h' is protected by
`DECLSPEC_DEPRECATED`, and if a user defines it on themselves, they will get
warnings about redefinition.
I did not imply that it is supposed to be defined by users, I just tried
to explain the behaviour of WinSDK's strsafe.h, with respect to inclusion
of other headers.
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?
There is a difference about these two approaches: `#pragma deprecated`
effects warnings, while defining those names to non-exitent ones effects hard
errors.
That's true, there's a difference between warnings and hard errors - I
understand that you want to mimic this aspect of the WinSDK headers.
Including 'dontuse.h' and getting hard errors might be expected, but
including 'strsafe.h' and getting accidental hard errors is probably
unwanted.
There's a bit of difference here. The dontuse.h header affects symbols
defined in other headers, making sure that one does not use symbols that
otherwise would be fine to use.
The functions within the DEPRECATE_SUPPORTED block in strsafe.h are not
defined elsewhere, they are all inline functions within strsafe.h. So
there is no way of having code that otherwise works, then you include
strsafe.h and suddenly it no longer works.
That's why I think it might be fine to just keep the hard error defines
for these functions, unconditionally as long as we don't have any #pragma
deprecate anyway.
// Martin
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
