Peter N Lewis wrote:
The code is portable if the interfaces are generated automatically. That bit has not been implemented unfortunately, and since requires parsing C headers, is quite challenging, so the interfaces are generated manually. Other than that, coding to the sockets layer is certainly portable.
I was referring to the manual header translation. Lacking a fully automatic tool (which is indeed very challenging and hopefully possible at all), C wrappers are the second best solution (just as safe, with only a little (in this case) overhead).
Here, a little C wrapper can easily use the system header definitions, and since it's only needed for setting up/closing a connection etc., while the actual socket I/O can go through regular files, the (anyway small) performance overhead should be negligible.
I'm not sure what you mean by "regular files".
Well, Pascal file types.
Personally, I do network transfer code that has to transfer at the speed of the harddisk, so I prefer to avoid any wrapping in the actual transfer,
Of course, Pascal files are "wrapped" by the Pascal runtime. If that's too much for you and, I assume, you're using direct read(2)/write(2) for the harddisk files involved, then you might have to do the same for the sockets, indeed.
Ideally we'd have direct access to the POSIX API on any given system, but until we can parse the C headers on each platform to make Pascal interfaces, that's probably not going to happen. The next best thing might be to make a Posix.pas file for each platform that is generated somewhat automatically and somewhat manually.
As I said, for connect etc., wrappers should be no problem. And read/write is done just the same as for other files, including the error handling. If that's lacking in some regard, it might be better to improve it in the RTS (for all files).
Frank