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

MacOSX.sdk/System/Library/Frameworks/Kernel.framework/Headers/os/availability.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.

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

Regards,
Akihiko Odaki

> 
> Best regards,
> Christian Schoenebeck
> 
>