[PATCH] D27827: [ObjC] CodeGen support for @available on macOS

Nico Weber via cfe-commits cfe-commits at lists.llvm.org
Fri Dec 16 14:32:07 PST 2016


https://developer.apple.com/library/content/releasenotes/General/CarbonCoreDeprecations/index.html#//apple_ref/doc/uid/TP40012224-CH1-SW16
explicitly suggests sysctl as replacement when targeting 10.8+, which
strongly suggests that it'll work.

On Fri, Dec 16, 2016 at 4:37 PM, Erik Pilkington via Phabricator <
reviews at reviews.llvm.org> wrote:

> erik.pilkington added a comment.
>
> I seem to remember that mapping from kernel versions to marketing versions
> was tossed around as a potential alternative to Gestalt. I think that the
> problem was Apple sometimes introduces (or reserves the right to introduce)
> new SDKs in a patch release (ie, Z in X.Y.Z), which wouldn't necessary
> imply a new kernel version, and would still need to be queried by
> @available. This makes it impossible to use kernel version in the general
> case (Or at least I think, it would be nice if someone internal to Apple
> could confirm this?). This rules out using `sysctl()` and the like.
>
> AFAIK this just leaves `Gestalt()` and Objective-C's `NSProcessInfo`, the
> latter would mean pulling in the Objective-C runtime, which would be
> unfortunate for C users (using the `__builtin_available` spelling). I don't
> think `Gestalt()` is in any danger of actually being removed, so we might
> as well use it. The only alternative I know of to those would be manually
> parsing the `SystemVersion.plist` XML file, but I think that might cause
> problems with sandboxed processes (right?). Any thoughts here would be much
> appreciated, `Gestalt()` is by no means a perfect solution.
>
> Compiler-rt does seem like a good place it put this, should I move the
> runtime code there instead?
>
> Thanks for taking a look!
> Erik
>
>
> https://reviews.llvm.org/D27827
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20161216/2d90ae1d/attachment.html>


More information about the cfe-commits mailing list