On Montag, 10. Januar 2022 21:39:28 CET Akihiko Odaki wrote:
On 2022/01/11 5:22, Christian Schoenebeck wrote:
On Montag, 10. Januar 2022 20:01:40 CET Akihiko Odaki wrote:
On 2022/01/11 3:46, Christian Schoenebeck wrote:
On Montag, 10. Januar 2022 19:20:15 CET Akihiko Odaki wrote:
On 2022/01/10 22:22, Peter Maydell wrote:
On Mon, 10 Jan 2022 at 13:14, Christian Schoenebeck
<qemu_oss@crudebyte.com> wrote:
I'd suggest to use:
#if !defined(MAC_OS_VERSION_12_0) ||
(MAC_OS_X_VERSION_MAX_ALLOWED < MAC_OS_VERSION_12_0)
#define kAudioObjectPropertyElementMain
kAudioObjectPropertyElementMaster
#endif
This is also how we do this for existing checks of this sort,
like the one in osdep.h for qemu_thread_jit_execute().
-- PMM
If I understand correctly, Many macOS-specific codes already no longer
complies with GCC because they depend on modern features GCC doesn't
provide. The most problematic construction is block; it is extensively
used by Apple's ABI and API and you cannot avoid using it even if you
try.
You mean Obj-C blocks? That's working with GCC for decades. I am not
aware
about any recent changes to Obj-C block mechanisms by Apple.
Also, note that MAC_OS_X_VERSION_MAX_ALLOWED defines the upper bound of
the supported version. The lower bound should be preferred here because
the usage of the new identifier is applied regardless of the version of
the host system. It is in contrary to the usage of
MAC_OS_X_VERSION_MAX_ALLOWED in osdep.h where the new interfaces are
used only for the newer versions. The lower bound is defined as
MAC_OS_X_VERSION_MIN_REQUIRED. Practically there is no difference of
the
two macros because they have the same value in QEMU and
kAudioObjectPropertyElementMain is a constant resolved compile-time,
but
it is still nice to have the code semantically correct.
For this particular enum: no, MAC_OS_X_VERSION_MAX_ALLOWED is the
correct
one. This is about whether enum kAudioObjectPropertyElementMain is
defined in the SDK header files. That's all. And the new enum
kAudioObjectPropertyElementMain is pure refactoring of the enum's old
name due to social reasons ("Master"). The actual reflected numeric
value
and semantic of the enum is unchanged and the resulting binary and
behaviour are identical.
There are a few problems with the usage of MAC_OS_X_VERSION_MAX_ALLOWED:
- The deprecation warning is designed to work with
MAC_OS_X_VERSION_MIN_REQUIRED. You may verify that with:
cc -mmacosx-version-min=12.0 -x c - <<EOF
#include <CoreAudio/CoreAudio.h>
int main()
{
int k = kAudioObjectPropertyElementMaster;
}
EOF
That's actually interesting. On other projects I definitely saw deprecated
warnings before on API declarations that were deprecated at a version
higher than the project's minimum deployment target.
Did they change that?
I don't think so. The behavior is documented at:
https://clang.llvm.org/docs/AttributeReference.html#availability
and the example refers to OS X 10.4, 10.6, 10.7. Probably they haven't
changed the behavior for decades.
The descriptions is very vague. It sais e.g. "If Clang is instructed to
compile code for macOS 10.6 ...". So it is describing it only via singular
version per example. We are talking about version ranges however.
MacOSX.sdk/System/Library/Frameworks/Kernel.framework/Headers/os/availabilit
y.h says manually defining API_TO_BE_DEPRECATED can alter the behavior so
that may be the case.
- The programmer must be aware whether it is constant or not.
- The macro tells about the runtime and not the SDK. There is no way to
tell the SDK version and that is why I suggested __is_identifier at the
first place. However, now I'm convinced that
MAC_OS_X_VERSION_MIN_REQUIRED is the better option because of the above
reasons.
If you make it dependent on MAC_OS_X_VERSION_MIN_REQUIRED, people with
older SDKs (e.g. Xcode <=13.0) would get a compiler error.
__is_identifier is the only option if you need a compatibility with the
older SDKs while specifying a greater version for
MAC_OS_X_VERSION_MIN_REQUIRED. It also applies to
MAC_OS_X_VERSION_MAX_ALLOWED; they give the possible runtime versions
and not the SDK version.
I have never used __is_identifier() for such things. I always used
MAC_OS_X_VERSION_MIN_REQUIRED and MAC_OS_X_VERSION_MAX_ALLOWED and it was
always doing the job.
And for symbols: those are automatically weak linked by the compiler if the
project's minimum deployment target is lower than the introductory version of
the symbol.
You are right about the deprecated warning not being emitted in the
example
above, currently not sure why, but I still think
MAC_OS_X_VERSION_MAX_ALLOWED is the way to go in this case.
The page and the header file I referred the above would help
understanding the behavior.
Yeah, I already checked that. It basically translates to:
__attribute__((availability(macosx,introduced=10.0,deprecated=12.0)))
So next I would need to read clang sources how this attribute is implemented
exactly. Not today. ;-)
Best regards,
Christian Schoenebeck