Hi John, > [...] >> This is a pitch to make [`errno`][1]-setting functions properly usable, as >> in having a guarantee to get the correct `errno` value on failure of a >> [system call][2]. Currently, functions which set `errno` are just exported >> in the Darwin/Glibc modules with (as far as I understand) no guaranteed >> correct way of handling errors as the correct `errno` value can't be >> retrieved. >> This means that much of the Swift code which uses Darwin/Glibc out there >> relies on behaviour that isn't guaranteed. > > Is this a general enough problem to be worth complicating the importer with > vs., say, just manually wrapping the POSIX APIs to be throwing in an overlay? > POSIX uses a lot of different conventions for reporting that an error > occurred, and there's only a finite set of POSIX APIs. Are there "user" > functions that wrap POSIX and carefully report errors with errno?
That's a very good point. I'm sure there are "user libraries" out there which set errno but I'd hope that it's a fairly limited set. So I think an overlay that ships with Swift and makes the underlying module unavailable would be fine by me. Something like the Dispatch module (which uses the "hidden" CDispatch module internally) sounds reasonable to me. The reason I proposed to include that into the clang importer is because the Darwin/Glibc modules contain hundreds (I haven't counted) of functions (syscall and library functions) that set errno. And I assumed that if it can be done automatically we could leverage that. > [...] Thanks, Johannes _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
