[swift-evolution] fcntl() should be added to the standard library.

[Bill Abt]

Yes,  I closed the original PR and created a new one that consolidates the changes into a single commit.  Dmitri just reviewed it and asked me to make a few formatting changes.  I’ve just completed them and am doing a build on both OS X and Linux.  When that’s complete, I’ve written a small Swift test program that I’ll compile with the newly built compiler.  Assuming all goes well, I’ll push these last set of changes and it should be good to go.

-Bill

> On Dec 10, 2015, at 8:17 PM, Ted Kremenek <kremenek at apple.com> wrote:
> 
> I agree Chris’s points here.
> 
> One of the original reasons the SDK Overlay was conceived was to help massage the interface between C APIs (such as ones using variadics) and Swift.  This seems right in that category.  I think for changes like this all that is needed is a code owner to review these changes.  I don’t think this needs to go through the swift-evolution process unless it is a major API change.
> 
> Bill: do you still have a pull request handy for this change?
> 
> Ted
> 
>> On Dec 5, 2015, at 11:11 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>>> 
>>> On Dec 4, 2015, at 8:36 PM, Bill Abt <babt at me.com <mailto:babt at me.com>> wrote:
>>> 
>>> The fcntl() API is a variadic standard “C” library and as such not supported currently by Swift.  Any visit to GitHub looking for a socket implementation will invariably find a .c or .mm file included that exposes fcntl() to Swift via a shim.  There are only 3 forms of this API, all returning int.  The first takes 2 integers and sets the 3rd to 0.  The second takes 3 integers.  The last and final form take 2 integers and a void pointer.  Looking at the standard library source, it’s trivial to implement.  It’ll take longer to write the tests than it will to write the functions.  Once implemented, it would eliminate the need for shims for this API.
>>> 
>>> This seems like one of those obvious things that just haven’t been implemented yet, no?
>> 
>> Hi Bill,
>> 
>> The Swift standard library doesn’t provide this sort of functionality, but I agree that it makes sense for the Darwin/Glibc modules to provide this interface.  We have a system of “overlays” to provide functionality that the clang importer can’t do automatically.  For example, the Glibc overlay is here:
>> https://github.com/apple/swift/blob/master/stdlib/public/Glibc/Glibc.swift <https://github.com/apple/swift/blob/master/stdlib/public/Glibc/Glibc.swift>
>> 
>> The darwin overlay is more filled out:
>> https://github.com/apple/swift/blob/master/stdlib/public/SDK/Darwin/Darwin.swift <https://github.com/apple/swift/blob/master/stdlib/public/SDK/Darwin/Darwin.swift>
>> 
>> It doesn’t look like it provides fcntl specifically, but it does provide open, which has the same varargs sort of implementation issues.  Adding support for fcntl to the overlays makes sense in principle to me.
>> 
>> -Chris
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151210/f43bf2db/attachment.html>