> On Nov 4, 2016, at 1:12 AM, Johannes Weiß <[email protected]> wrote: > > Hi, > > I just realised, that the problem is slightly worse than I originally > described. I believed that successful calls in between the actual call the > programmer wanted to make and capturing `errno` are not a problem. > > But POSIX seems to suggest [4] that "The setting of errno after a successful > call to a function is unspecified unless the description of that function > specifies that errno shall not be modified." . The Linux man page [5] also > mentions that "a function that succeeds is allowed to change errno." > > To me this means that the issue is wider than just ARC. I think the problem > extends to memory allocations on the heap. Failed memory allocations aren't a > problem because they are terminal in Swift. However, _successful_ memory > allocations might be a problem because the malloc(3) that the Swift compiler > will use is absolutely free to set errno to 0 (or any other value in fact) > indicating success. (Said that at least malloc doesn't change `errno` on the > macOS or Linux I tested today, we probably shouldn't rely on that though.) > > This makes it even more unpredictable to the programmer what a use of `errno` > in Swift will return. IMHO it shouldn't be exported to Swift as its value is > undefined almost(?) everywhere. > > [4]: http://pubs.opengroup.org/onlinepubs/9699919799/functions/errno.html > [5]: http://man7.org/linux/man-pages/man3/errno.3.html
Swift's implicit allocations don't directly use malloc/free. If there is a platform where a successful malloc dirties errno, we should avoid doing so in the Swift runtime's entry points. -Joe _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
