qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC PATCH v2 2/6] audio/coreaudio: Remove a deprecation warning on


From: Akihiko Odaki
Subject: Re: [RFC PATCH v2 2/6] audio/coreaudio: Remove a deprecation warning on macOS 12
Date: Tue, 11 Jan 2022 04:01:40 +0900
User-agent: Mozilla/5.0 (X11; Linux aarch64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0

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
- 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.


There are other cases where MAC_OS_X_VERSION_MIN_REQUIRED (a.k.a. "minimum
deployment target") would be used instead: macOS APIs that might be available
to only some, but not to the entire macOS version range officially supported
by the rolled out binary. Did you see any particular case where this is
incorrectly used in QEMU?

Best regards,
Christian Schoenebeck


Assuming the correctness of the use MAC_OS_X_VERSION_MAX_ALLOWED is irrelevant with the nature of the identifier (constant or not), the same problem is in ui/cocoa.m:
#ifndef MAC_OS_X_VERSION_10_13
#define MAC_OS_X_VERSION_10_13 101300
#endif

/* 10.14 deprecates NSOnState and NSOffState in favor of
 * NSControlStateValueOn/Off, which were introduced in 10.13.
 * Define for older versions
 */
#if MAC_OS_X_VERSION_MAX_ALLOWED < MAC_OS_X_VERSION_10_13
#define NSControlStateValueOn NSOnState
#define NSControlStateValueOff NSOffState
#endif

Regards,
Akihiko Odaki



reply via email to

[Prev in Thread] Current Thread [Next in Thread]