Bug 279886

Summary: wrong implemetaion of kern_getpeername when client side closed.
Product: Base System Reporter: Horse Ma <shichun_ma>
Component: kernAssignee: Gleb Smirnoff <glebius>
Status: Closed Not A Bug    
Severity: Affects Many People    
Priority: ---    
Version: CURRENT   
Hardware: Any   
OS: Any   
Attachments:
Description Flags
test app for the peername none

Description Horse Ma 2024-06-21 04:25:34 UTC
Created attachment 251596 [details]
test app for the peername

for the define of getpeername() system call returns the name of the peer connected to socket s. it doesn't require keeping connected when do the query.
one example is: one client connects a socket,then send msg to that socket, and close.from server side, it still can recv msg from the socket even after client socket is closed. attached one test application to show the case.
Comment 1 Gleb Smirnoff freebsd_committer freebsd_triage 2024-06-21 04:55:27 UTC
Hi,

I believe this is not a bug.  Per specification the getpeername(2) shall
return name only if the socket is connected, otherwise it shall return
ENOTCONN.  Your test program confirms this behaviour.  Here is the
specification:

https://pubs.opengroup.org/onlinepubs/9699919799/functions/getpeername.html

The FreeBSD manual page says the same.

The fact that socket holds buffered data (e.g. you can read(2) on it) doesn't
mean that socket is connected.

If you don't mind, I'm going to close this bug as not a bug.
Comment 2 Horse Ma 2024-06-21 05:44:55 UTC
when run same test application on linux system, it will not not return error.
The "connected" can be undestandard as once connected.
Comment 3 Gleb Smirnoff freebsd_committer freebsd_triage 2024-06-21 13:48:58 UTC
On Fri Jun 21 05:44:55  2024 UTC, shichun_ma@dell.com wrote:
> when run same test application on linux system, it will not not return error.

This means Linux doesn't follow POSIX specification, and that's their
bug.

> The "connected" can be undestandard as once connected.

How would you understand "not connected" then? :)