Sample program for Accept not working lazarus / 38-Networking and Web Programming ---------------------------------------------------------------------- Pyewacket · 2025-02-23 10:55 I am trying to implement a simple TCP server that accepts a single connection. I am using the sample program found at  https://www.freepascal.org/docs- html/current/rtl/sockets/fpaccept.html This example does not compile server.pas(38,23) Error: Call by var for arg no. 2 has to match exactly: Got "ShortString" expected "sockaddr_in" server.pas(39,33) Warning: Variable "FromName" does not seem to be initialized server.pas(49,4) Fatal: There were 1 errors compiling module, stopping Is the sample wrong or do I miss something? Why does the sample for fpaccept use Accept? ---------------------------------------------------------------------- MarkMLl · 2025-02-23 11:08 The sample's wrong, raise a bug report against the documentation. The usage of Accept() with a string is marked deprecated at https://www.freepascal.org/docs-html/current/rtl/sockets/index-5.html . There's one or two situations where you do have to use the "original" functions rather than the ones prefixed fp, but you'd be strongly advised to avoid that unless absolutely necessary. Working code at e.g. https://github.com/MarkMLl/telnetsrv/blob/main/telnetserver.pas roughly line 720 , but the bottom line is that you need to set up a data structure containing the binary socket address etc. MarkMLl ---------------------------------------------------------------------- Pyewacket · 2025-02-23 15:13 Quoteraise a bug report against the documentation. How do I do that? ---------------------------------------------------------------------- MarkMLl · 2025-02-23 15:18 Quote from: Pyewacket on February 23, 2025, 04:13:56 pmQuoteraise a bug report against the documentation. How do I do that? Left a bit... up a bit... bugtracker link. I was looking around a bit after posting, and I think the only time you need to use Accept() etc. (i.e. without the fp prefix) is when you want to associate a socket with a (text or binary) file. However even then there are problems, since there's no way of specifying whether you want AF_INET or AF_INET6 (etc.), or that you want to use unix- domain sockets (etc.). I can't remember the rationale for all the fp functions (i.e. rather than going direct to the kernel API), but I've got a very vague recollection that they add various signal handlers (i.e. retry interrupted syscalls etc.). MarkMLl ---------------------------------------------------------------------- Pyewacket · 2025-02-24 17:13 Quoteraise a bug report against the documentation. I did as you suggested but erroneously in the FPC project as I was not aware of a separate documentation project. However, I got an interesting reply: QuoteThe general consensus regarding examples in the documentation seems that they do not have to make sense nor actually have to work. They are present to show how a certain function could be used. Kind of a strange attitude, especially towards beginners who rely on example code. Why bother with examples in documentation at all if you can't rely on them. ---------------------------------------------------------------------- MarkMLl · 2025-02-24 17:57 Quote from: Pyewacket on February 24, 2025, 06:13:38 pmKind of a strange attitude, especially towards beginners who rely on example code. Why bother with examples in documentation at all if you can't rely on them. I agree, but I'm not a member of the core team. You've done your bit by raising it in the best possible place, I'm trying to do mine by helping you. MarkMLl ---------------------------------------------------------------------- wp · 2025-02-24 19:08 Quote from: Pyewacket on February 24, 2025, 06:13:38 pmHowever, I got an interesting reply: QuoteThe general consensus regarding examples in the documentation seems that they do not have to make sense nor actually have to work. They are present to show how a certain function could be used. Kind of a strange attitude, especially towards beginners who rely on example code. I cannot believe that this was written by a team member (maybe be a frustrated user?). Can you post the link to your bug report? ---------------------------------------------------------------------- MarkMLl · 2025-02-24 19:17 Quote from: wp on February 24, 2025, 08:08:14 pmI cannot believe that this was written by a team member (maybe be a frustrated user?). Can you post the link to your bug report? https://gitlab.com/freepascal.org/fpc/source/-/issues/41157 MarkMLl ---------------------------------------------------------------------- TRon · 2025-02-24 21:29 Quote from: Pyewacket on February 23, 2025, 11:55:00 amThis example does not compile Compiles just fine. Code: Bash  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i fpc -B server.pas Free Pascal Compiler version 3.2.2 [2021/05/16] for x86_64Copyright (c) 1993-2021 by Florian Klaempfl and othersTarget OS: Linux for x86-64Compiling server.passerver.pas(37,6) Warning: Symbol "Accept" is deprecatedLinking server48 lines compiled, 0.0 sec1 warning(s) issued  QuoteIs the sample wrong or do I miss something? Why does the sample for fpaccept use Accept? The part that is missing (or actually added/set by your used configuration) is ansistring. The latter is probably an oversight aka copy-paste error (or in this case referring to the exact same example code). Yes, good idea, let us make all examples work for all compiler modes/settings and for all platforms. Always nice to start learning about a programing language by requiring to know how exactly the pre- processor works. While at it add proper error handling as well. ---------------------------------------------------------------------- dbannon · 2025-02-25 02:54 Seems strange that the doc page for fpaccept() uses the more direct accept() in its example. Quite different signatures. Davo ---------------------------------------------------------------------- TRon · 2025-02-25 06:25 Both entries of these functions in the documentation simply points to the same example. ---------------------------------------------------------------------- Pyewacket · 2025-03-02 20:36 QuoteYes, good idea, let us make all examples work for all compiler modes/settings What compiler mode did you use for your working compile? I'm not aware of having changed that afterninstall but who knows... ---------------------------------------------------------------------- TRon · 2025-03-02 20:50 Quote from: Pyewacket on March 02, 2025, 09:36:53 pmWhat compiler mode did you use for your working compile? See example, it is explicitly set (for a reason as a compiler mode has further implications). ---------------------------------------------------------------------- dbannon · 2025-03-03 10:07 TRon, did you test the app once compiled. Seems to me, while it compiled, it does not work as claimed. My recommendation is the examples in packages/fcl- net/examples/isock* Davo ---------------------------------------------------------------------- tetrastes · 2025-03-03 11:00 Quote from: Pyewacket on March 02, 2025, 09:36:53 pm QuoteYes, good idea, let us make all examples work for all compiler modes/settings What compiler mode did you use for your working compile? I'm not aware of having changed that afterninstall but who knows... This example compiles for unix, but not for windows. Accept with the second argument String exists in fpcsrc/packages/rtl- extra/src/unix/sockets.pp. ---------------------------------------------------------------------- marcov · 2025-03-03 11:46 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 valuereturned 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 · 2025-03-03 12:54 Quote from: marcov on March 03, 2025, 12:46:57 pmThe 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 valuereturned 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. QuoteSome 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 · 2025-03-03 22:46 Quote from: marcov on March 03, 2025, 12:46:57 pmSome 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