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

[Akihiko Odaki]

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