Skip to content
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

FoundationEssentials: perform explicit conversion of mode_t #522

Closed
wants to merge 1 commit into from

Conversation

compnerd
Copy link
Collaborator

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.

@compnerd
Copy link
Collaborator Author

@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) {
Copy link
Contributor

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?

Copy link
Collaborator Author

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.
@shahmishal
Copy link
Member

@swift-ci test windows

@@ -24,6 +24,10 @@
#include <libkern/OSThermalNotification.h>
#endif

#if defined(_WIN32)
typedef int mode_t;
Copy link
Member

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?

Copy link
Collaborator Author

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.

@compnerd compnerd marked this pull request as draft April 10, 2024 16:52
@compnerd
Copy link
Collaborator Author

Let's hold off on this. I think that the recent FileManager work has been different than the original swift-corelibs-foundation support work. There has been more replacement here with native Windows APIs rather than the compatible APIs which allows us to reduce the locations where we reference mode_t and thus we might end up in a place where we do not need this after all.

@compnerd
Copy link
Collaborator Author

compnerd commented May 1, 2024

Going to close this off. Instead of addressing the mode_t issues, it is better to use Win32 APIs directly and avoid the POSIX type matching.

@compnerd compnerd closed this May 1, 2024
@compnerd compnerd deleted the mode_t branch May 1, 2024 20:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants