Sample program for Accept not working

[Pyewacket]

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]

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]

raise a bug report against the documentation.

How do I do that?

[MarkMLl]

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

[Pyewacket]

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:

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.

[MarkMLl]

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

[wp]

However, I got an interesting reply:

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?

[MarkMLl]

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

[TRon]

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.  

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.

[dbannon]

Seems strange that the doc page for fpaccept() uses the more direct accept() in its example. Quite different signatures.

Davo

[TRon]

Both entries of these functions in the documentation simply points to the same example.

[Pyewacket]

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

[TRon]

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).

[dbannon]

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

[tetrastes]

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.