Sample program for Accept not working

[marcov]

The FP functions were introduced in 2.0 (and the 1.9.x betas before it) to sanitize the 1.0.x situation which had an own error handling convention that

• Always updated an error value
• returned true or false for errors

and were non-standard in many ways. One of the problems was that some calls were implemented on some unices with multiple syscalls, and when switching the RTL from syscalls to libc. Some of the reasons are named in http://www.stack.nl/~marcov/unixrtl.pdf

So the new FP functions were introduced to remedy that and got a prefix because posix names are very general, and some are equal to FPC keywords like read and write.

Other core members wanted to hold on to the functions for compatibility for a while. The oldlinux unit was finally removed in 3.0.x, and the Linux stat record being an union with 1.0.x era field names was also finally erased by afaik Sven for 3.2.x or so.
 
Some functions like the socket to file descriptor stuff are a grey area too. Afaik the original implementors maintained that they are fine, but bugreports about them (and especially about errorhandling) linger forever. Probably they are fine for simplistic scripting use, but not to base applications on?

[MarkMLl]

The FP functions were introduced in 2.0 (and the 1.9.x betas before it) to sanitize the 1.0.x situation which had an own error handling convention that

• Always updated an error value
• returned true or false for errors

and were non-standard in many ways. One of the problems was that some calls were implemented on some unices with multiple syscalls, and when switching the RTL from syscalls to libc. Some of the reasons are named in http://www.stack.nl/~marcov/unixrtl.pdf

So the new FP functions were introduced to remedy that and got a prefix because posix names are very general, and some are equal to FPC keywords like read and write.

Other core members wanted to hold on to the functions for compatibility for a while. The oldlinux unit was finally removed in 3.0.x, and the Linux stat record being an union with 1.0.x era field names was also finally erased by afaik Sven for 3.2.x or so.

Thanks for the details and the link.

Some functions like the socket to file descriptor stuff are a grey area too. Afaik the original implementors maintained that they are fine, but bugreports about them (and especially about errorhandling) linger forever. Probably they are fine for simplistic scripting use, but not to base applications on?

I used Connect() with a textfile parameter in the 3.2.0 era (in the context of a unix-domain socket, we might have discussed it at the time) and while I'd not claim to have run it for 1000s of hours in production code it certainly worked.

However the current primary problem is not so much with the description of Accept(), as with https://www.freepascal.org/docs-html/current/rtl/sockets/fpaccept.html which basically trots out the Accept() example verbatim using a parameter list grossly different from what is documented at the top of the same page.

The secondary problem is that nobody came down hard on whoever added "The general consensus regarding examples in the documentation seems that they do not have to make sense nor actually have to work." to the bug report at https://gitlab.com/freepascal.org/fpc/source/-/issues/41157 , which hardly paints the overall project in a favourable light.

MarkMLl

[dbannon]

Some of the reasons are named in http://www.stack.nl/~marcov/unixrtl.pdf

Wow, interesting read. And insight to the inner working of the team.....

Davo