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