-
Notifications
You must be signed in to change notification settings - Fork 194
FoundationEssentials: perform explicit conversion of mode_t
#522
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
@swift-ci please test |
let preferredChunkSize = filestat.st_blksize | ||
#if !NO_FILESYSTEM | ||
let shouldMap = shouldMapFileDescriptor(fd, path: inPath, options: options) | ||
#else | ||
let shouldMap = false | ||
#endif | ||
|
||
if fileType != S_IFREG { | ||
if fileType != mode_t(S_IFREG) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For my reference, could you elaborate a bit more on why these casts are all necessary? What type is S_IFREG
on Windows? Does it use some other integer type, or does it use int
? If so I think I'd expect that declaring a typealias mode_t = Int
(or the appropriate integer type) would eliminate the need for these casts because S_IFREG
would be considered the same type was fileType
here. Or is there a detail I might be missing here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is no mode_t
on Windows, there is an alias that I have created which is int
. However, the type system often sees the values as UInt16
which would then be incompatible with int
. The explicit casting avoids the mismatched types on the various sides.
Windows uses `int` instead of a `mode_t` type. Create a shim alias in `_CShims` and use explicit type conversions to allow sharing of code paths across platforms. This helps reduce some of the build errors enabling further work to re-enable building FoundationEssentials on Windows.
@swift-ci test windows |
@@ -24,6 +24,10 @@ | |||
#include <libkern/OSThermalNotification.h> | |||
#endif | |||
|
|||
#if defined(_WIN32) | |||
typedef int mode_t; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What does mode_t
mean on Windows? Why would we want Foundation to use UNIX/POSIX APIs on Windows?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It means fewer code path divergences. Having a large number of #if os(...)
conditionals hampers the ability to maintain the code path. Using the same terminology just is a convenience that is worth it. In general, Windows does have enough of the POSIX specification implemented to qualify as a POSIX compatible environment.
Let's hold off on this. I think that the recent |
Going to close this off. Instead of addressing the |
Windows uses
int
instead of amode_t
type. Create a shim alias in_CShims
and use explicit type conversions to allow sharing of code paths across platforms. This helps reduce some of the build errors enabling further work to re-enable building FoundationEssentials on Windows.