In our previous episode, Jonas Maebe said: > > sb > > wants to support and modernize them, I have no problem with that. > > But that > > hasn't happened since 2005-2007 or so.
The modernize bit above also refers to the changes done during the 2.0 RTL update, the functions still have a 1.0.x signature: - Name (fp-) - parameter typing - parameter returnvalue. IOW return a proper -1 Besides that the Unix socket unit has extra overload versions which are used in the examples, which means that the examples only work on *nix. > What needs to be modernised about it? > It's not like our disk i/o error > code handles many more different error codes, nor are those errors > much more specific There are specific disk related error codes defined. Not for sockets. IIRC there is no way to distinguish between a clean disconnect and an unexpected error. The information is lost, since the error is cached nowhere. Attempts with non-blocking sockets will block unless fpread returns ewouldblock and ewouldblock<>eagain The above is a bit grasping at straws from memory(the attempts below) and a quick look. The problem IMHO is more that nobody knows. > I remember the old discussion, but I never understood how the error > reporting of the sockets code and the generic I/O code differed in a way > that made the former worse than the latter. >From what I remember, several people tried to create a simple chat server example with it (when Ales was starting out with lnet), and failed miserably. That is the only serious attempt at every doing something with these that I know. If I'm honest, they were experimenting with non-blocking sockets too though, so that might have confused the picture though. Btw the number of reactions to the deprecation has been mostly zero. > > That would also make it possible to directly map socketerror to > > getlastresult/fpgeterrno, instead of caching it in another threadvar. > > IIRC the problem with removing socketerror would be that it could > easily break existing code (given that socketerror is not overwritten > by calls other than those from the sockets unit). True. And that behaviour was never deprecated because "socketerror" was considered needed to abstract socket errors in an OS dependent manner when sockets also was expanded to be supported on Windows. I never considered the proper deprecation way (deprecating socketerror, introducing a new function) worth the trouble, specially since the number of users with such code are probably extremely low (since all pre 1.0.x functions that rely on it are removed or deprecated, oldlinux isn't compiled anymore etc) I always assume these functions would either be removed or moved and updated anyway. _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
