One of the challenges we have in removing imports in public headers is that other projects are importing those headers transitively. Someone else may be assuming they get stdio.h by importing CoreFoundation.h or dispatch.h, and using something from that header.
- Tony > On Aug 19, 2016, at 11:53 AM, William Dillon via swift-corelibs-dev > <swift-corelibs-dev@swift.org> wrote: > > Hi all, > > In corelibs-foundation project we've been using a patch based on > https://github.com/apple/swift-corelibs-foundation/pull/399/files > <https://github.com/apple/swift-corelibs-foundation/pull/399/files> for quite > some time (summary: remove #include <stdio.h>). The PR hasn't gotten any > where for various reasons. Currently, I've gotten libdispatch working on > arm, but it requires a fix that's essentially identical. It is part of a PR > available here: https://github.com/apple/swift-corelibs-libdispatch/pull/155 > <https://github.com/apple/swift-corelibs-libdispatch/pull/155> > > I'd like to get this moving forward in both cases, and I'd like to bring it > to the list. What exactly is stdio.h bringing in? I realize the comment > identifies __off_t, but at least on arm that's being provided elsewhere. > Furthermore, __off_t is defined in several places. > > Are there any suggestions for what a satisfactory solution would be to > address the duplicate definition of va_list on arm that does not negatively > impact other platforms? > > Thanks, > - Will > _______________________________________________ > swift-corelibs-dev mailing list > swift-corelibs-dev@swift.org > https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
_______________________________________________ swift-corelibs-dev mailing list swift-corelibs-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
