Use PlatformFileHandle abstraction instead of int type for file descriptors in cross-platform code.
Created attachment 249606 [details] Patch
Why do we want to do this?
(In reply to comment #2) > Why do we want to do this? Well, this is supposed to be cross-platform code. Not all platforms / ports use 'int' as type for file descriptors (for e.g. GTK uses GFileIOStream*). We already use the PlatformFileHandle abstraction for cross-platform code inside WebCore. Other ports may be interested in using the NetworkCache and having POSIX assumptions inside supposed-to-be cross-platform code is not going to help.
Note that we already use the WebCore FileSystem abstraction in the NetworkCache because of this. That abstraction is dealing with PlatformFileHandle handles, not ints.
Comment on attachment 249606 [details] Patch It would be better if people making ports do something like this if they find it helpful. Are there any platforms that can't use unix style fd's these days? Note that the existing code doesn't use any PlatformFileHandle based abstractions, just the string ones.
(In reply to comment #5) > Comment on attachment 249606 [details] > Patch > > It would be better if people making ports do something like this if they > find it helpful. Are there any platforms that can't use unix style fd's > these days? Note that the existing code doesn't use any PlatformFileHandle > based abstractions, just the string ones. Well, I thought the GTK port might have issues with this. GTK is not unix-only and AFAIK the Midori browser works on Windows. Anyway, I disagree with the decision as I think it is a slippery slope to start using unix-specific things in cross-platform headers but I am going to close this since I don't have any stakes in this. The GTK or EFL port guys can always reopen if they wish to make this change.
(In reply to comment #6) > Anyway, I disagree with the decision as I think it is a slippery slope to > start using unix-specific things in cross-platform headers but I am going to > close this since I don't have any stakes in this. The GTK or EFL port guys > can always reopen if they wish to make this change. WebKitGTK+ doesn't have Windows or OS X support at the moment. We lost it with the switch to WebKit2. There is no need to keep the abstraction around for our sake. If we manage to start the onerous task of creating WebKit2GTK+ for Windows, we will be happy to re-add the abstraction at that time.
Ok, thanks for the feedback Martin.