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 6:05, Christian Schoenebeck wrote:
> 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.

That would not happen with older SDKs because they don't know even 
whether the identifier is a symbol. That is usually not a problem though 
because such a problem happens only when the version range specified 
MAC_OS_X_VERSION_MIN_REQUIRED and MAC_OS_X_VERSION_MAX_ALLOWED are not 
supported by the SDK.

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

It is because the compiler only checks the minimum. The upper bound is a 
purely library-defined construct.

MacOSX.sdk/usr/include/Availability.h says:
 > The min OS version is specified as an option to the compiler:
 > -mmacosx-version-min=10.x when building for Mac OS X, and 
-miphoneos-version-min=y.z
 > when building for the iPhone.  The upper bound for the OS version is 
rarely needed,
 > but it can be set on the command line via: 
-D__MAC_OS_X_VERSION_MAX_ALLOWED=10x0 for
 > Mac OS X and __IPHONE_OS_VERSION_MAX_ALLOWED = y0z00 for iOS.

As you can see here, the maximum is just a macro, unlike the minimum.

Regards,
Akihiko Odaki