Instead of looping 8 times to work around the TOCTOU issue with sizing the current directory buffer, instead keep doubling the buffer up until the 32767 character limit until the result fits. This ensures we always get a working directory if GetWorkingDirectoryW didn't return some other error, rather than returning nil in the case of a race condition.
On Windows, there is a built-in maximum path limitation of 260 characters under most conditions. This can be extended to 32767 characters under either of the following two conditions:
- Adding the longPathAware attribute to the executable's manifest AND enabling the LongPathsEnabled system-wide registry key or group policy.
- Ensuring fully qualified paths passed to Win32 APIs are prefixed with \?\
Unfortunately, the former is not realistic for the Swift ecosystem, since it requires developers to have awareness of this specific Windows limitation, AND set longPathAware in their apps' manifest AND expect end users of those apps to change their system configuration.
Instead, this patch transparently prefixes all eligible paths in calls to Win32 APIs with the \?\ prefix to allow them to work with paths longer than 260 characters without requiring the caller of Foundation to manually prefix the paths.
See https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation for more info.
* (146349351) Support NS/CFURL re-core in Swift
* Fix .fileSystemPath() calls in Windows test
* Use encoded strings for .absoluteURL, fix NSURL bridging and CFURL lastPathComponent edge cases
* Add workaround for crash on Linux
* Fix typo
GetBinaryType will return ERROR_BAD_EXE_FORMAT when querying an arm64 executable from an x86 process running on an ARM system. This change switches the implementation to use SHGetFileInfoW, which isn't subject to this quirk.
This also makes isExecutableFile behave more similarly to other platforms -- e.g. isExecutableFile already returns true for any file with the execute bit, even for an arm64 executable on an x86_64 macOS system (which it can't actually run). The spirit of the API is that the file is of an executable type, not necessarily that the running system is capable of executing it.
The practical consequence of fixing this bug is that queries like:
```swift
FileManager.default.isExecutableFile(atPath: "C:\\Windows\\system32\\cmd.exe")
```
will now correctly return true regardless of what architecture the binary is compiled for or what type of system it's running on.
Closes#860
* Advise porter on where to make necessary change.
In #1075 the change was already made for BSD (thank you!); my working
edit had this guidance to ensure future porters get an error directing
them where to make a necessary change.
Otherwise, the FoundationEssentials build will fail and complain these
variables are not defined but not have guidance as to where they are
sourced from.
* OpenBSD does not support extended attributes.
* OpenBSD does not have secure_getenv.
* Remaining OpenBSD changes.
* OpenBSD also needs `pthread_mutex_t?`.
* Originally I followed Darwin's check with `d_namlen`, but this should
work too.
* Correct statvfs type casts for OpenBSD.
On OpenBSD, fsblkcnt_t -- the type of f_blocks -- is a UInt64; therefore,
so must `blockSize` be.
Ultimately, both sides of the `totalSizeBytes` multiplication should
probably be type cast for all platforms, but that's a more significant
functional change for another time.
* Default activeProcessorCount to 1, not 0.
After a rather tedious debugging session trying to figure out why
swiftpm-bootstrap appeared to be deadlocked, this turned out to be the
culprit. Perhaps this should be #error instead, but for now, set a
sensible default.
* Use sysconf for activeProcessorCount.
This is what Dispatch does in some places for OpenBSD anyway, so do
likewise here.
05975959e67f57063445baabb652262dd764cc72 added a use of `O_NONBLOCK` but
the constant cannot be imported from wasi-libc through ClangImporter
directly, so we need to add a shim for it as well as other constants.
* Revert "Revert "rdar://142693100 (Allocationless constant String -> NSString bridging via a new tagged pointer type) (#2798)" (#2843)"
This reverts commit c378439322f5b960ecb972b27ab1419a622ad6b2.
* Adopt the new entry point for bridging the new tagged pointers
* All remaining callsites passed null-terminated strings, so just eliminate the isTerminated bit and simplify further. Also gets us up to 13 bits of length
* Address review comments
* [wasm] Make `FileManager.createFile()` work on WASI
fixesswiftwasm/swift#5593
`FileManager.createFile()` currently doesn't work on WASI because it
requires `.atomic`, it requires creating a temporary file, and it isn't
suppported on WASI.
So I have fixed that by removing the `.atomic` requirement only on WASI.
* [wasm] Make `Data.WritingOptions.atomic` unavailable on WASI
`writeToFileAux`, `createTemporaryFile`, and `createProtectedTemporaryFile` also become unavailable on WASI.
* Add an upcall point to swift-corelibs-foundation for String encoding conversion
* Add upcall for conversion from bytes to String in non-swift-foundation encodings
* Add an HTTP format style for both `Date` and `DateComponents`.
* Correct the comments to properly use DateComponents type
* Use default values instead of crashing when formatting date components with missing or invalid fields
* Use 59 seconds instead of 0 for leap second of 60 - this results in being off by only 1 second in this case instead of 59.
* Address some review feedback
Some app is passing in `value: -9223372036854775808` to the function below, and force unwrapping the result. It then crashes when the force unwrap fails.
```swift
/// - returns: A new date, or nil if a date could not be calculated with the given input.
public func date(byAdding component: Component, value: Int, to date: Date, wrappingComponents: Bool = false) -> Date?
```
This is caused by #1149. Prior to the change, we were using `_CalendarICU`'s implementation, where we truncate the input value to `Int32`, which becomes 0 in this case. That results in us returning the input `date` unchanged.
Now with #1149, we truthfully return `nil` because the calculation cannot be done.
We could restore the old behavior, but that implementation is incorrect. It's also clearly a wrong assumption on the client side. Add a compatibility check and restore the old behavior if needed.
Resolves 145862455
* (145233243) Use lstat() semantics for URL directory detection
* Fix Windows try?, fix symlink path in test
* Check for reparse point flag explicitly
* Move path.isEmpty check outside
* AttributedString index validity APIs
* Move canImport(Synchronization) into function body
* Remove unnecessary bounds checks from validity expression
* Update FOUNDATION_FRAMEWORK code to provide Index versions
* Make decoding go fast!
* Fixes
* Use typed throws everywhere to prevent allocation in the unhappy path.
* cleanup
* More cleanup
* Fix tests
* Removed Chromium callout in function name
This PR implements the API changes proposed in SF-0014 by adding a new DiscontiguousAttributedSubstring type (the result of slicing an AttributedString with a RangeSet) which vends out slices of each underlying view, an upgraded Runs view which now handles discontiguous segments, and performs operations over the discontiguous subranges.
