IMHO it seems reasonable for Foundation to return the contents of procfs items when constructing Data. That being said - I would probably favor a more structured parsing for actually using that resultant Data than just a blob. Those structured elements are probably not very portable so perhaps they belong in something above Foundation.
I don’t know of any linux variants off hand that don’t have /proc, but it might be interesting to somehow detect if that is truly a procfs element. I think it would perhaps be a failure if just the path /proc is special cased; Android, Solaris and Plan9 also share this same concept iirc (there are likely others). > On Jan 12, 2017, at 11:40 AM, Carl Brown1 via swift-corelibs-dev > <swift-corelibs-dev@swift.org> wrote: > > Hi, > > I run the Austin Swift meetup group, and a question came up about the /proc > filesystem on Linux: > > The question involved the inability to get any useful information from > Data(contentsOf: URL(fileURLWithPath: "/proc/sys/fs/file-max")). > > It turns out that Data(contentsOf:) does a stat() on the inode of the file > you give it, and then runs alloc()/read() for the specified number of bytes. > This works fine on normal files on normal file systems. But all the files in > /proc have a 0 length specified by their inodes, and you have to actually > read them until EOF to find out how much is there. > > So the question is: Is that something the *Programmer* should be responsible > for knowing, or should *Foundation* be responsible for handling that > correctly? > > I can see a case that we'd want to avoid embedding things this OS-specific in > Foundation, but on the other hand, I know that this is very confusing for > Darwin developers moving to Linux and expecting Data(contentsOf:) to "Just > work." > > So I thought I'd ask the community and see if there was a consensus. > > Thanks, > > -Carl > > -- > Carl Brown > Swift@IBM > carl.bro...@ibm.com > > _______________________________________________ > 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
