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

[Christian Schoenebeck <qemu_oss@crudebyte.com>]

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?

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

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.

Best regards,
Christian Schoenebeck