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

[Akihiko Odaki <akihiko.odaki@gmail.com>]

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