You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+1-1
Original file line number
Diff line number
Diff line change
@@ -11,7 +11,7 @@ It is designed with these goals in mind:
11
11
12
12
There is more information on the Foundation framework [here](https://developer.apple.com/library/mac/documentation/Cocoa/Reference/Foundation/ObjC_classic/).
13
13
14
-
This project, `swift-corelibs-foundation`, provides an compatibility implementation of the Foundation API for platforms where there is no Objective-C runtime. On macOS, iOS, and other Apple platforms, apps should use the Foundation that comes with the operating system.
14
+
This project, `swift-corelibs-foundation`, provides a compatibility implementation of the Foundation API for platforms where there is no Objective-C runtime. On macOS, iOS, and other Apple platforms, apps should use the Foundation that comes with the operating system.
// This section of _CFBundleCreate touches the disk, so it should be done outside the lock. This avoids blocking threads which are just attempting to get an existing bundle on file system access, potentially from a lower-piority thread.
787
+
// This section of _CFBundleCreate touches the disk, so it should be done outside the lock. This avoids blocking threads which are just attempting to get an existing bundle on file system access, potentially from a lower-priority thread.
// This method returns all the statically linked bundles. This includes the main bundle as well as any frameworks that the process was linked against at launch time. It does not include frameworks or opther bundles that were loaded dynamically.
1744
+
// This method returns all the statically linked bundles. This includes the main bundle as well as any frameworks that the process was linked against at launch time. It does not include frameworks or other bundles that were loaded dynamically.
// Since we no longer allow bundles to be removed from tables, this method does nothing. Modifying the tables during deallocation is risky because if the caller has over-released the bundle object then we will deadlock on the global lock.
92
92
#ifTARGET_OS_OSX
93
93
if (_useUnsafeUnretainedTables()) {
94
-
// Except for special cases of unsafe-unretained, where we must clean up the table or risk handing out a zombie object. There may still be outstanding pointers to these bundes (e.g. the result of CFBundleGetBundleWithIdentifier) but there is nothing we can do about that after this point.
94
+
// Except for special cases of unsafe-unretained, where we must clean up the table or risk handing out a zombie object. There may still be outstanding pointers to these bundles (e.g. the result of CFBundleGetBundleWithIdentifier) but there is nothing we can do about that after this point.
if (!foundGregLeap|| !foundGregLeapMatchesComps) {
1756
1756
if (strictMatching) {
1757
1757
if (isGregorianCalendar) {
1758
-
*exactMatch= false; // We couldn't find what we needed but we found sumthin. Step C will decide whether or not to NULL the date out.
1758
+
*exactMatch= false; // We couldn't find what we needed but we found something. Step C will decide whether or not to NULL the date out.
1759
1759
} else {
1760
1760
// For other calendars (besides Chinese which is already being handled), go to the top of the next period for the next highest unit of the one that bailed.
/* Another critical ICU design issue. Similar to conversion error, source pointer returned from U_BUFFER_OVERFLOW_ERROR is already beyond the last valid character position. It renders the returned value from source entirely unusable. We have to manually back up until succeeding <rdar://problem/7183045> Intrestingly, this issue doesn't apply to ucnv_toUnicode. The asynmmetric nature makes this more dangerous */
266
+
/* Another critical ICU design issue. Similar to conversion error, source pointer returned from U_BUFFER_OVERFLOW_ERROR is already beyond the last valid character position. It renders the returned value from source entirely unusable. We have to manually back up until succeeding <rdar://problem/7183045> Interestingly, this issue doesn't apply to ucnv_toUnicode. The asynmmetric nature makes this more dangerous */
// If the numbering system for `localeIDWithDesiredComponents` is compatible with the constructed locale’s language and is not already the default numbering system (index 0), then set it on the new locale, e.g. `hi_IN@numbers=latn` + `ar` shoudl get `ar_IN@numbers=latn`, since `latn` is valid for `ar`.
543
+
// If the numbering system for `localeIDWithDesiredComponents` is compatible with the constructed locale’s language and is not already the default numbering system (index 0), then set it on the new locale, e.g. `hi_IN@numbers=latn` + `ar` should get `ar_IN@numbers=latn`, since `latn` is valid for `ar`.
// <rdar://problem/51409572> CFLocaleCopyCurrent() failed to look up current locale -- gpsd dameon is not localized, does not interact directly with users
726
+
// <rdar://problem/51409572> CFLocaleCopyCurrent() failed to look up current locale -- gpsd daemon is not localized, does not interact directly with users
727
727
// This log was added to try to catch scenarios in which apps fail to look up the current locale thanks to sandboxing issues or CFPreferences issues. It turns out that in its current formulation, this log has a high false positive rate and is very confusing.
// Do not try fallback if string encoding is requested AND a script is present in the passed-in locale since the script might affect the string encoding: <rdar://problem/54531339>
0 commit comments