Lazarus

Programming => Networking and Web Programming => Topic started by: Pyewacket on February 23, 2025, 11:55:00 am

Title: Sample program for Accept not working
Post by: Pyewacket on February 23, 2025, 11:55:00 am
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?
Title: Re: Sample program for Accept not working
Post by: MarkMLl on February 23, 2025, 12:08:40 pm
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
Title: Re: Sample program for Accept not working
Post by: Pyewacket on February 23, 2025, 04:13:56 pm
Quote
raise a bug report against the documentation.

How do I do that?

Title: Re: Sample program for Accept not working
Post by: MarkMLl on February 23, 2025, 04:18:48 pm
Quote from: Pyewacket on February 23, 2025, 04:13:56 pm
Quote
raise 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
Title: Re: Sample program for Accept not working
Post by: Pyewacket on February 24, 2025, 06:13:38 pm
Quote
raise 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:

Quote
The 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.



Title: Re: Sample program for Accept not working
Post by: MarkMLl on February 24, 2025, 06:57:39 pm
Quote from: Pyewacket on February 24, 2025, 06:13:38 pm
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.

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
Title: Re: Sample program for Accept not working
Post by: wp on February 24, 2025, 08:08:14 pm
Quote from: Pyewacket on February 24, 2025, 06:13:38 pm
However, I got an interesting reply:

Quote
The 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?
Title: Re: Sample program for Accept not working
Post by: MarkMLl on February 24, 2025, 08:17:53 pm
Quote from: wp on February 24, 2025, 08:08:14 pm
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?

https://gitlab.com/freepascal.org/fpc/source/-/issues/41157

MarkMLl
Title: Re: Sample program for Accept not working
Post by: TRon on February 24, 2025, 10:29:18 pm
Quote from: Pyewacket on February 23, 2025, 11:55:00 am
This example does not compile
Compiles just fine.

Code: Bash  [Select][+][-]
  1. fpc -B server.pas
  2. Free Pascal Compiler version 3.2.2 [2021/05/16] for x86_64
  3. Copyright (c) 1993-2021 by Florian Klaempfl and others
  4. Target OS: Linux for x86-64
  5. Compiling server.pas
  6. server.pas(37,6) Warning: Symbol "Accept" is deprecated
  7. Linking server
  8. 48 lines compiled, 0.0 sec
  9. 1 warning(s) issued
  10.  

Quote
Is 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. :P
Title: Re: Sample program for Accept not working
Post by: dbannon on February 25, 2025, 03:54:21 am
Seems strange that the doc page for fpaccept() uses the more direct accept() in its example. Quite different signatures.

Davo
Title: Re: Sample program for Accept not working
Post by: TRon on February 25, 2025, 07:25:26 am
Both entries of these functions in the documentation simply points to the same example.
Title: Re: Sample program for Accept not working
Post by: Pyewacket on March 02, 2025, 09:36:53 pm

Quote
Yes, 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...


Title: Re: Sample program for Accept not working
Post by: TRon on March 02, 2025, 09:50:39 pm
Quote from: Pyewacket on March 02, 2025, 09:36:53 pm
What 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).
Title: Re: Sample program for Accept not working
Post by: dbannon on March 03, 2025, 11:07:51 am
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 <FPC>packages/fcl-net/examples/isock*

Davo
Title: Re: Sample program for Accept not working
Post by: tetrastes on March 03, 2025, 12:00:23 pm
Quote from: Pyewacket on March 02, 2025, 09:36:53 pm

Quote
Yes, 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.
Title: Re: Sample program for Accept not working
Post by: marcov on March 03, 2025, 12:46:57 pm
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


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?
Title: Re: Sample program for Accept not working
Post by: MarkMLl on March 03, 2025, 01:54:10 pm
Quote from: marcov on March 03, 2025, 12:46:57 pm
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.

Quote
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
Title: Re: Sample program for Accept not working
Post by: dbannon on March 03, 2025, 11:46:29 pm
Quote from: marcov on March 03, 2025, 12:46:57 pm
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
TinyPortal © 2005-2018