Re: [RFC PATCH v2 2/6] audio/coreaudio: Remove a deprecation warning on macOS 12
On Dienstag, 11. Januar 2022 13:35:05 CET Christian Schoenebeck wrote:
> Curiousity was stronger: the original clang behaviour was as I explained:
> https://github.com/llvm-mirror/clang/commit/0a0d2b179085a52c10402feebeb6db8b
> 4d96a140#diff-97c4322e86bf436b7f79f4fcafc4b7beb092da08c5c23f294f98b5bb0a7f9a
> 31
>
> Quote:
>
> "
> For example,
>
> void foo()
>
> __attribute__((availability(macosx,introduced=10.2,deprecated=10.4,obsolete
> d=10.6)));
>
> ...
>
>- If we choose a deployment target >= Mac OS X 10.4, uses of "foo"
> will result in a deprecation warning, as if we had placed
> attribute((deprecated)) on it ...
> "
>
> Relevant code section (in that original commit):
>
> static AvailabilityResult CheckAvailability(ASTContext ,
> const AvailabilityAttr *A,
> std::string *Message) {
> ...
> VersionTuple TargetMinVersion = Context.Target.getPlatformMinVersion();
> ...
> // Make sure that this declaration hasn't been deprecated.
> if (!A->getDeprecated().empty() && TargetMinVersion >= A->getDeprecated())
Stupid me, you are right. No deprecated warning unless minimum deployment
target is >= the attribute's deprecated version.
So it was always like this. My bad. :)
> { if (Message) {
> Message->clear();
> llvm::raw_string_ostream Out(*Message);
> Out << "first deprecated in " << PrettyPlatformName << ' '
> << A->getDeprecated();
> }
>
> return AR_Deprecated;
> }
> ...
> }
Best regards,
Christian Schoenebeck
Re: [RFC PATCH v2 2/6] audio/coreaudio: Remove a deprecation warning on macOS 12
On Montag, 10. Januar 2022 22:05:43 CET 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
> > >
> > > wrote:
> > 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 - < > >> #include
> > >>
> > >> 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/availabil
> > it 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.
>
> > > 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. ;-)
Curiousity was stronger: the original clang behaviour was as I explained:
Re: [RFC PATCH v2 2/6] audio/coreaudio: Remove a deprecation warning on macOS 12
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
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 - <
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
Re: [RFC PATCH v2 2/6] audio/coreaudio: Remove a deprecation warning on macOS 12
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
> >
> > 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 - < >> #include
> >>
> >> 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.
> > You are
Re: [RFC PATCH v2 2/6] audio/coreaudio: Remove a deprecation warning on macOS 12
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
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 - <
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
Re: [RFC PATCH v2 2/6] audio/coreaudio: Remove a deprecation warning on macOS 12
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
> >>>
> >>> 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 - < #include
>
> 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
Re: [RFC PATCH v2 2/6] audio/coreaudio: Remove a deprecation warning on macOS 12
On Mon, 10 Jan 2022 at 19:01, Akihiko Odaki wrote: > 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 It's tempting to fix that one by just deleting the ifdeffery, since cocoa.m already doesn't compile on 10.13 (it uses NSPasteboardTypeOwner, which was only introduced in 10.14)... -- PMM
Re: [RFC PATCH v2 2/6] audio/coreaudio: Remove a deprecation warning on macOS 12
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
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 - <
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
Re: [RFC PATCH v2 2/6] audio/coreaudio: Remove a deprecation warning on macOS 12
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
> >
> > 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 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
Re: [RFC PATCH v2 2/6] audio/coreaudio: Remove a deprecation warning on macOS 12
On 2022/01/10 22:22, Peter Maydell wrote: On Mon, 10 Jan 2022 at 13:14, Christian Schoenebeck 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. 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. Regards, Akihiko Odaki
Re: [RFC PATCH v2 2/6] audio/coreaudio: Remove a deprecation warning on macOS 12
On Mon, 10 Jan 2022 at 13:14, Christian Schoenebeck 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
Re: [RFC PATCH v2 2/6] audio/coreaudio: Remove a deprecation warning on macOS 12
On 1/10/22 14:07, Christian Schoenebeck wrote:
> On Montag, 10. Januar 2022 13:24:06 CET Philippe Mathieu-Daudé wrote:
>> On 1/10/22 09:44, Philippe Mathieu-Daudé wrote:
>>> On 1/10/22 09:17, Akihiko Odaki wrote:
On 2022/01/10 2:06, Philippe Mathieu-Daudé wrote:
> When building on macOS 12 we get:
>
>audio/coreaudio.c:50:5: error: 'kAudioObjectPropertyElementMaster'
> is deprecated: first deprecated in macOS 12.0
> [-Werror,-Wdeprecated-declarations]
>kAudioObjectPropertyElementMaster
>^
>kAudioObjectPropertyElementMain
>
> /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frame
> works/CoreAudio.framework/Headers/AudioHardwareBase.h:208:5: note:
> 'kAudioObjectPropertyElementMaster' has been explicitly marked
> deprecated here
>kAudioObjectPropertyElementMaster
> API_DEPRECATED_WITH_REPLACEMENT("kAudioObjectPropertyElementMain",
> macos(10.0, 12.0), ios(2.0, 15.0), watchos(1.0, 8.0), tvos(9.0, 15.0))
> = kAudioObjectPropertyElementMain
>^
>
> Use kAudioObjectPropertyElementMain (define it to
> kAudioObjectPropertyElementMaster on macOS < 12).
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> audio/coreaudio.c | 16 ++--
> 1 file changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/audio/coreaudio.c b/audio/coreaudio.c
> index d8a21d3e507..c836bc9dd37 100644
> --- a/audio/coreaudio.c
> +++ b/audio/coreaudio.c
> @@ -44,10 +44,14 @@ typedef struct coreaudioVoiceOut {
> bool enabled;
> } coreaudioVoiceOut;
> +#if !defined(MAC_OS_VERSION_12_0)
> +#define kAudioObjectPropertyElementMain
> kAudioObjectPropertyElementMaster
> +#endif
> +
Semantically MAC_OS_VERSION_12_0 defines the numeric value of version
12.0 and its existence does not mean that
kAudioObjectPropertyElementMain is defined. I suggest the following:
#if !__is_identifier(kAudioObjectPropertyElementMain)
#define kAudioObjectPropertyElementMain kAudioObjectPropertyElementMaster
#endif
>>
>> Apparently __is_identifier() is Clang specific. It might be acceptable
>> since this file is restricted to macOS. Similarly for the other
>> block/file-posix.c patch, the section is conditional to __APPLE__
>> being defined.
>
> Correct, __is_identifier() is a clang extension and does not work with GCC
> (tested). I would not use it. People on Mac usually use clang, but there are
> also cross compilers for macOS binaries.
>
> 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
Uh I just posted v3. I didn't test GCC. I'll wait for more comment on v3
then repost v4 with your suggestion, thanks.
Re: [RFC PATCH v2 2/6] audio/coreaudio: Remove a deprecation warning on macOS 12
On Montag, 10. Januar 2022 13:24:06 CET Philippe Mathieu-Daudé wrote:
> On 1/10/22 09:44, Philippe Mathieu-Daudé wrote:
> > On 1/10/22 09:17, Akihiko Odaki wrote:
> >> On 2022/01/10 2:06, Philippe Mathieu-Daudé wrote:
> >>> When building on macOS 12 we get:
> >>>
> >>>audio/coreaudio.c:50:5: error: 'kAudioObjectPropertyElementMaster'
> >>> is deprecated: first deprecated in macOS 12.0
> >>> [-Werror,-Wdeprecated-declarations]
> >>>kAudioObjectPropertyElementMaster
> >>>^
> >>>kAudioObjectPropertyElementMain
> >>>
> >>> /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frame
> >>> works/CoreAudio.framework/Headers/AudioHardwareBase.h:208:5: note:
> >>> 'kAudioObjectPropertyElementMaster' has been explicitly marked
> >>> deprecated here
> >>>kAudioObjectPropertyElementMaster
> >>> API_DEPRECATED_WITH_REPLACEMENT("kAudioObjectPropertyElementMain",
> >>> macos(10.0, 12.0), ios(2.0, 15.0), watchos(1.0, 8.0), tvos(9.0, 15.0))
> >>> = kAudioObjectPropertyElementMain
> >>>^
> >>>
> >>> Use kAudioObjectPropertyElementMain (define it to
> >>> kAudioObjectPropertyElementMaster on macOS < 12).
> >>>
> >>> Signed-off-by: Philippe Mathieu-Daudé
> >>> ---
> >>> audio/coreaudio.c | 16 ++--
> >>> 1 file changed, 10 insertions(+), 6 deletions(-)
> >>>
> >>> diff --git a/audio/coreaudio.c b/audio/coreaudio.c
> >>> index d8a21d3e507..c836bc9dd37 100644
> >>> --- a/audio/coreaudio.c
> >>> +++ b/audio/coreaudio.c
> >>> @@ -44,10 +44,14 @@ typedef struct coreaudioVoiceOut {
> >>> bool enabled;
> >>> } coreaudioVoiceOut;
> >>> +#if !defined(MAC_OS_VERSION_12_0)
> >>> +#define kAudioObjectPropertyElementMain
> >>> kAudioObjectPropertyElementMaster
> >>> +#endif
> >>> +
> >>
> >> Semantically MAC_OS_VERSION_12_0 defines the numeric value of version
> >> 12.0 and its existence does not mean that
> >> kAudioObjectPropertyElementMain is defined. I suggest the following:
> >> #if !__is_identifier(kAudioObjectPropertyElementMain)
> >> #define kAudioObjectPropertyElementMain kAudioObjectPropertyElementMaster
> >> #endif
>
> Apparently __is_identifier() is Clang specific. It might be acceptable
> since this file is restricted to macOS. Similarly for the other
> block/file-posix.c patch, the section is conditional to __APPLE__
> being defined.
Correct, __is_identifier() is a clang extension and does not work with GCC
(tested). I would not use it. People on Mac usually use clang, but there are
also cross compilers for macOS binaries.
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
Best regards,
Christian Schoenebeck
Re: [RFC PATCH v2 2/6] audio/coreaudio: Remove a deprecation warning on macOS 12
On 1/10/22 09:44, Philippe Mathieu-Daudé wrote:
> On 1/10/22 09:17, Akihiko Odaki wrote:
>> On 2022/01/10 2:06, Philippe Mathieu-Daudé wrote:
>>> When building on macOS 12 we get:
>>>
>>> audio/coreaudio.c:50:5: error: 'kAudioObjectPropertyElementMaster'
>>> is deprecated: first deprecated in macOS 12.0
>>> [-Werror,-Wdeprecated-declarations]
>>> kAudioObjectPropertyElementMaster
>>> ^
>>> kAudioObjectPropertyElementMain
>>>
>>> /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/CoreAudio.framework/Headers/AudioHardwareBase.h:208:5:
>>> note: 'kAudioObjectPropertyElementMaster' has been explicitly marked
>>> deprecated here
>>> kAudioObjectPropertyElementMaster
>>> API_DEPRECATED_WITH_REPLACEMENT("kAudioObjectPropertyElementMain",
>>> macos(10.0, 12.0), ios(2.0, 15.0), watchos(1.0, 8.0), tvos(9.0, 15.0))
>>> = kAudioObjectPropertyElementMain
>>> ^
>>>
>>> Use kAudioObjectPropertyElementMain (define it to
>>> kAudioObjectPropertyElementMaster on macOS < 12).
>>>
>>> Signed-off-by: Philippe Mathieu-Daudé
>>> ---
>>> audio/coreaudio.c | 16 ++--
>>> 1 file changed, 10 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/audio/coreaudio.c b/audio/coreaudio.c
>>> index d8a21d3e507..c836bc9dd37 100644
>>> --- a/audio/coreaudio.c
>>> +++ b/audio/coreaudio.c
>>> @@ -44,10 +44,14 @@ typedef struct coreaudioVoiceOut {
>>> bool enabled;
>>> } coreaudioVoiceOut;
>>> +#if !defined(MAC_OS_VERSION_12_0)
>>> +#define kAudioObjectPropertyElementMain
>>> kAudioObjectPropertyElementMaster
>>> +#endif
>>> +
>>
>> Semantically MAC_OS_VERSION_12_0 defines the numeric value of version
>> 12.0 and its existence does not mean that
>> kAudioObjectPropertyElementMain is defined. I suggest the following:
>> #if !__is_identifier(kAudioObjectPropertyElementMain)
>> #define kAudioObjectPropertyElementMain kAudioObjectPropertyElementMaster
>> #endif
Apparently __is_identifier() is Clang specific. It might be acceptable
since this file is restricted to macOS. Similarly for the other
block/file-posix.c patch, the section is conditional to __APPLE__
being defined.
Re: [RFC PATCH v2 2/6] audio/coreaudio: Remove a deprecation warning on macOS 12
On 1/10/22 09:17, Akihiko Odaki wrote:
> On 2022/01/10 2:06, Philippe Mathieu-Daudé wrote:
>> When building on macOS 12 we get:
>>
>> audio/coreaudio.c:50:5: error: 'kAudioObjectPropertyElementMaster'
>> is deprecated: first deprecated in macOS 12.0
>> [-Werror,-Wdeprecated-declarations]
>> kAudioObjectPropertyElementMaster
>> ^
>> kAudioObjectPropertyElementMain
>>
>> /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/CoreAudio.framework/Headers/AudioHardwareBase.h:208:5:
>> note: 'kAudioObjectPropertyElementMaster' has been explicitly marked
>> deprecated here
>> kAudioObjectPropertyElementMaster
>> API_DEPRECATED_WITH_REPLACEMENT("kAudioObjectPropertyElementMain",
>> macos(10.0, 12.0), ios(2.0, 15.0), watchos(1.0, 8.0), tvos(9.0, 15.0))
>> = kAudioObjectPropertyElementMain
>> ^
>>
>> Use kAudioObjectPropertyElementMain (define it to
>> kAudioObjectPropertyElementMaster on macOS < 12).
>>
>> Signed-off-by: Philippe Mathieu-Daudé
>> ---
>> audio/coreaudio.c | 16 ++--
>> 1 file changed, 10 insertions(+), 6 deletions(-)
>>
>> diff --git a/audio/coreaudio.c b/audio/coreaudio.c
>> index d8a21d3e507..c836bc9dd37 100644
>> --- a/audio/coreaudio.c
>> +++ b/audio/coreaudio.c
>> @@ -44,10 +44,14 @@ typedef struct coreaudioVoiceOut {
>> bool enabled;
>> } coreaudioVoiceOut;
>> +#if !defined(MAC_OS_VERSION_12_0)
>> +#define kAudioObjectPropertyElementMain
>> kAudioObjectPropertyElementMaster
>> +#endif
>> +
>
> Semantically MAC_OS_VERSION_12_0 defines the numeric value of version
> 12.0 and its existence does not mean that
> kAudioObjectPropertyElementMain is defined. I suggest the following:
> #if !__is_identifier(kAudioObjectPropertyElementMain)
> #define kAudioObjectPropertyElementMain kAudioObjectPropertyElementMaster
> #endif
OK, thank you!
> Regards,
> Akihiko Odaki
Re: [RFC PATCH v2 2/6] audio/coreaudio: Remove a deprecation warning on macOS 12
On 2022/01/10 2:06, Philippe Mathieu-Daudé wrote:
When building on macOS 12 we get:
audio/coreaudio.c:50:5: error: 'kAudioObjectPropertyElementMaster' is
deprecated: first deprecated in macOS 12.0 [-Werror,-Wdeprecated-declarations]
kAudioObjectPropertyElementMaster
^
kAudioObjectPropertyElementMain
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/CoreAudio.framework/Headers/AudioHardwareBase.h:208:5:
note: 'kAudioObjectPropertyElementMaster' has been explicitly marked
deprecated here
kAudioObjectPropertyElementMaster
API_DEPRECATED_WITH_REPLACEMENT("kAudioObjectPropertyElementMain", macos(10.0,
12.0), ios(2.0, 15.0), watchos(1.0, 8.0), tvos(9.0, 15.0)) =
kAudioObjectPropertyElementMain
^
Use kAudioObjectPropertyElementMain (define it to
kAudioObjectPropertyElementMaster on macOS < 12).
Signed-off-by: Philippe Mathieu-Daudé
---
audio/coreaudio.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/audio/coreaudio.c b/audio/coreaudio.c
index d8a21d3e507..c836bc9dd37 100644
--- a/audio/coreaudio.c
+++ b/audio/coreaudio.c
@@ -44,10 +44,14 @@ typedef struct coreaudioVoiceOut {
bool enabled;
} coreaudioVoiceOut;
+#if !defined(MAC_OS_VERSION_12_0)
+#define kAudioObjectPropertyElementMain kAudioObjectPropertyElementMaster
+#endif
+
Semantically MAC_OS_VERSION_12_0 defines the numeric value of version
12.0 and its existence does not mean that
kAudioObjectPropertyElementMain is defined. I suggest the following:
#if !__is_identifier(kAudioObjectPropertyElementMain)
#define kAudioObjectPropertyElementMain kAudioObjectPropertyElementMaster
#endif
Regards,
Akihiko Odaki
static const AudioObjectPropertyAddress voice_addr = {
kAudioHardwarePropertyDefaultOutputDevice,
kAudioObjectPropertyScopeGlobal,
-kAudioObjectPropertyElementMaster
+kAudioObjectPropertyElementMain
};
static OSStatus coreaudio_get_voice(AudioDeviceID *id)
@@ -69,7 +73,7 @@ static OSStatus coreaudio_get_framesizerange(AudioDeviceID id,
AudioObjectPropertyAddress addr = {
kAudioDevicePropertyBufferFrameSizeRange,
kAudioDevicePropertyScopeOutput,
-kAudioObjectPropertyElementMaster
+kAudioObjectPropertyElementMain
};
return AudioObjectGetPropertyData(id,
@@ -86,7 +90,7 @@ static OSStatus coreaudio_get_framesize(AudioDeviceID id,
UInt32 *framesize)
AudioObjectPropertyAddress addr = {
kAudioDevicePropertyBufferFrameSize,
kAudioDevicePropertyScopeOutput,
-kAudioObjectPropertyElementMaster
+kAudioObjectPropertyElementMain
};
return AudioObjectGetPropertyData(id,
@@ -103,7 +107,7 @@ static OSStatus coreaudio_set_framesize(AudioDeviceID id,
UInt32 *framesize)
AudioObjectPropertyAddress addr = {
kAudioDevicePropertyBufferFrameSize,
kAudioDevicePropertyScopeOutput,
-kAudioObjectPropertyElementMaster
+kAudioObjectPropertyElementMain
};
return AudioObjectSetPropertyData(id,
@@ -121,7 +125,7 @@ static OSStatus coreaudio_set_streamformat(AudioDeviceID id,
AudioObjectPropertyAddress addr = {
kAudioDevicePropertyStreamFormat,
kAudioDevicePropertyScopeOutput,
-kAudioObjectPropertyElementMaster
+kAudioObjectPropertyElementMain
};
return AudioObjectSetPropertyData(id,
@@ -138,7 +142,7 @@ static OSStatus coreaudio_get_isrunning(AudioDeviceID id,
UInt32 *result)
AudioObjectPropertyAddress addr = {
kAudioDevicePropertyDeviceIsRunning,
kAudioDevicePropertyScopeOutput,
-kAudioObjectPropertyElementMaster
+kAudioObjectPropertyElementMain
};
return AudioObjectGetPropertyData(id,
[RFC PATCH v2 2/6] audio/coreaudio: Remove a deprecation warning on macOS 12
When building on macOS 12 we get:
audio/coreaudio.c:50:5: error: 'kAudioObjectPropertyElementMaster' is
deprecated: first deprecated in macOS 12.0 [-Werror,-Wdeprecated-declarations]
kAudioObjectPropertyElementMaster
^
kAudioObjectPropertyElementMain
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/CoreAudio.framework/Headers/AudioHardwareBase.h:208:5:
note: 'kAudioObjectPropertyElementMaster' has been explicitly marked
deprecated here
kAudioObjectPropertyElementMaster
API_DEPRECATED_WITH_REPLACEMENT("kAudioObjectPropertyElementMain", macos(10.0,
12.0), ios(2.0, 15.0), watchos(1.0, 8.0), tvos(9.0, 15.0)) =
kAudioObjectPropertyElementMain
^
Use kAudioObjectPropertyElementMain (define it to
kAudioObjectPropertyElementMaster on macOS < 12).
Signed-off-by: Philippe Mathieu-Daudé
---
audio/coreaudio.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/audio/coreaudio.c b/audio/coreaudio.c
index d8a21d3e507..c836bc9dd37 100644
--- a/audio/coreaudio.c
+++ b/audio/coreaudio.c
@@ -44,10 +44,14 @@ typedef struct coreaudioVoiceOut {
bool enabled;
} coreaudioVoiceOut;
+#if !defined(MAC_OS_VERSION_12_0)
+#define kAudioObjectPropertyElementMain kAudioObjectPropertyElementMaster
+#endif
+
static const AudioObjectPropertyAddress voice_addr = {
kAudioHardwarePropertyDefaultOutputDevice,
kAudioObjectPropertyScopeGlobal,
-kAudioObjectPropertyElementMaster
+kAudioObjectPropertyElementMain
};
static OSStatus coreaudio_get_voice(AudioDeviceID *id)
@@ -69,7 +73,7 @@ static OSStatus coreaudio_get_framesizerange(AudioDeviceID id,
AudioObjectPropertyAddress addr = {
kAudioDevicePropertyBufferFrameSizeRange,
kAudioDevicePropertyScopeOutput,
-kAudioObjectPropertyElementMaster
+kAudioObjectPropertyElementMain
};
return AudioObjectGetPropertyData(id,
@@ -86,7 +90,7 @@ static OSStatus coreaudio_get_framesize(AudioDeviceID id,
UInt32 *framesize)
AudioObjectPropertyAddress addr = {
kAudioDevicePropertyBufferFrameSize,
kAudioDevicePropertyScopeOutput,
-kAudioObjectPropertyElementMaster
+kAudioObjectPropertyElementMain
};
return AudioObjectGetPropertyData(id,
@@ -103,7 +107,7 @@ static OSStatus coreaudio_set_framesize(AudioDeviceID id,
UInt32 *framesize)
AudioObjectPropertyAddress addr = {
kAudioDevicePropertyBufferFrameSize,
kAudioDevicePropertyScopeOutput,
-kAudioObjectPropertyElementMaster
+kAudioObjectPropertyElementMain
};
return AudioObjectSetPropertyData(id,
@@ -121,7 +125,7 @@ static OSStatus coreaudio_set_streamformat(AudioDeviceID id,
AudioObjectPropertyAddress addr = {
kAudioDevicePropertyStreamFormat,
kAudioDevicePropertyScopeOutput,
-kAudioObjectPropertyElementMaster
+kAudioObjectPropertyElementMain
};
return AudioObjectSetPropertyData(id,
@@ -138,7 +142,7 @@ static OSStatus coreaudio_get_isrunning(AudioDeviceID id,
UInt32 *result)
AudioObjectPropertyAddress addr = {
kAudioDevicePropertyDeviceIsRunning,
kAudioDevicePropertyScopeOutput,
-kAudioObjectPropertyElementMaster
+kAudioObjectPropertyElementMain
};
return AudioObjectGetPropertyData(id,
--
2.33.1
