I have a bunch of code that uses std::numericlimits<float>::quietNaN() and in some places I make checks like isnan(...). In Debug everything is fine but in Release isnan() does not work as expected and returns false even when a NAN is passed to isnan() function. Does anyone else have this problem? Is there some deprecation that Iam missing or some new compiler flag?

I have an application which uses Service Management framework to register a LaunchAgent. The LaunchAgent registers a mach service with a specific name and it listens for connections made by my application. Also the agent is registered relative to the app bundle using BundleProgram parameter in the agent plist. My problem is that after the initial registration the service always points to the path where my app bundle was located in the time of registration. Here is an example: I download my app from the AppStore and it places it in the /Applications directory. I open it and my service is registered. Then when I want to develop/debug/etc.. from Xcode I build the same app with the same service and I re-register the service from my Debug build and the service still points to the service in the /Applications directory. I tried the use case when I have two builds of my app with a different CFBundleVersion. The LaunchAgent version was the same as the version which made the initial registration, i.e. no matter which app version I use and that I re-register my service, still the initial registered version of the service is used. Based on the documentation in SMAppService.h: If an app updates either the plist or the executable for a LaunchAgent or LaunchDaemon, the SMAppService must be re-registered or it may not launch. It is recommended to also call unregister before re-registering if the executable has been changed. I think that re-registering the application should work in the aforementioned use cases. The only workaround I have found so far is: delete the application which made the initial registration of the service log out log in and open the desired app version and register the service with that version. Does anyone have the same problem and is there a more correct way to handle this use case? Is there a problem in the way I'm using the ServiceManagement framework? Should I write a feedback report to Apple about this problem?

I have a macOS application with a minimum version of macOS 12.0. I need to be able to get the current keyboard region designator. Example: The user selects a input source of English Canadian. What I want as a result of this fact is en-CA locale identifier. I get the current keyboard language with the following code func keyboardLanguage() -> String?{ let keyboard = TISCopyCurrentKeyboardInputSource().takeRetainedValue() let languagesPtr = TISGetInputSourceProperty(keyboard, kTISPropertyInputSourceLanguages)! let languages = Unmanaged<AnyObject>.fromOpaque(languagesPtr).takeUnretainedValue() as? [String] return languages?.first } This returns the language as en, but I don't see how I can get the region from Text Input Sources. I can get the input source id let keyboard = TISCopyCurrentKeyboardInputSource().takeRetainedValue() let idPtr = TISGetInputSourceProperty(keyboard, kTISPropertyInputSourceID)! let id = Unmanaged<AnyObject>.fromOpaque(idPtr).takeUnretainedValue() as? String print(String(describing: id)) This prints com.apple.keylayout.Canadian which points to the Canadian region but is not a region designator. I can possible parse this id and map it to a region designator but first I'm not sure if I will capture all of the regions and secondly what happens if the format of the id changes? If someone can point to the correct API to use it will be much appreciated.