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.
* [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.
* FreeBSD platform specific fixes
- Use "/usr/share/zoneinfo"
- Use platform specific types and values
- Implement extattr ops for FreeBSD
- Use copy_file_range(2) for file cloning
* Revise patch to ProcessInfo to reduce potential impact to other platforms
* Fix macOS build
* typo
* take suggested change
* [Android] Enable more code and tests
while disabling setting extended file attributes and a test creating a hard link,
features not normally allowed on Android.
* Remove incorrect WASI check
* Get FoundationEssentials building
Adding the missing musl imports to get FoundationEssentials building for
the Swift static SDKs again.
Also providing an option to disable building the macros. The macros
aren't necessary for building the library and will not be run as part of
the static SDK. No need to bloat the SDK or build times further. For
Swift 6, the macros should be provided by the toolchain since the
toolchain and SDK are current revlocked due to swiftmodules.
* Get FoundationInternationalization building
Adding the missing Musl imports to get FoundationInternationalization
building for the static SDK.
* [android] fix the LP32 armv7/i686 android build
* Update Sources/FoundationEssentials/Android+Extensions.swift
Co-authored-by: Jeremy Schonfeld <1004103+jmschonfeld@users.noreply.github.com>
* drop the android Lp32 specific operator &
---------
Co-authored-by: Jeremy Schonfeld <1004103+jmschonfeld@users.noreply.github.com>
* Add `import WASILibc` statements to libc import chains
* Declare wasm32 arch as 32-bit environment
* Switch to _pointerBitWidth for architecture checks
This change switches the architecture checks in Data.swift to use the
_pointerBitWidth instead of the arch() checks for consistency with newer
platforms.
* Guard out user/group related code on WASI
This change guards out the user/group related code on WASI, as WASI does
not have the concept of users or groups.
* Throw explicit unsupported error if trying to set user or group on WASI
Instead of implicitly ignoring user-given values, we should throw
exception to make it clear that those values cannot be set on WASI.
This commit guards out the extended attributes and file system
attributes related code on WASI as WASI does not support these
features. Just return nothing or ignore the set request.
* Use dynamic replacement instead of _typeByName for internationalization upcalls
* Make FOUNDATION_FRAMEWORK function non-dynamic
* Fix build failures
This adds the necessary guards and includes for the Android modules.
While the module does not compile currently due to nullability
differences (and in some cases missing declarations), this at least
brings the module to a point where we can start working on the errors
and differences to create a maintainable codebase for Android.
On non-Windows targets we ensure that the path exists when we attempt to
query the attributes of the path. This adds the same check on Windows so
that we can have similar behaviour on all platforms.
Follow the expected behaviour to drop invalid modification dates, e.g.
`+NaN`. This matches the semantics that are expected on Unix and avoids
a crash due to the initialiser.
This allows for us to use the constants without explicitly casting the
type to `DWORD` on each site of use. By providing the shadowing
overload we can simply use the constants without impacting the
readability of the surrounding code.
Add a helper for time conversion and remove some functions which do not
make sense on Windows - users are not identified by integral IDs but
rather by SIDs. This helps reduce the error diagnostics when building
FoundationEssentials on Windows.
This allows us to get further into building FoundationEssentials once
again on Windows. Much of the file system work has resulted in this
module no longer being viable on Windows and will need to be replaced to
allow building on Windows which does not have the `fts` APIs.
