bug#62990: 30.0.50; UDP server closes connection upon receiving an empty packet

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: 62990@debbugs.gnu.org,  mail@vasilij.de
> Date: Wed, 26 Apr 2023 13:47:49 +0200
> 
> >>>>> On Wed, 26 Apr 2023 13:38:47 +0300, Eli Zaretskii <eliz@gnu.org> said:
> 
>     >> From: Robert Pluim <rpluim@gmail.com>
>     >> Cc: 62990@debbugs.gnu.org,  mail@vasilij.de
>     >> Date: Wed, 26 Apr 2023 12:35:21 +0200
>     >> 
>     >> >>>>> On Wed, 26 Apr 2023 13:30:32 +0300, Eli Zaretskii <eliz@gnu.org> 
> said:
>     >> 
>     Eli> Do we want some variable to get back the old behavior, in case some
>     Eli> application out there depends on that?
>     >> 
>     >> For which one?
> 
>     Eli> The 2nd one.
> 
> I guess we could, but if the application asks us to send an empty
> packet we should do it.

I didn't say that the default behavior should be that, I just asked
whether it is conceivable that someone, somewhere could actually rely
on the semi-buggy behavior, whereby empty packets aren't sent?

>     >> Does it help if I say that [1] is a security fix? 😜
> 
>     Eli> No.  But it will help if you convince me that it's a bug-fix.
> 
> It transforms this:
> 
>     recvfrom(5, "hello", 4096, 0, {sa_family=AF_INET, sin_port=htons(56845), 
> sin_addr=inet_addr("127.0.0.1")}, [16]) = 5
>     Received string (5): "hello"
>     recvfrom(5, "", 4096, 0, {sa_family=AF_INET, sin_port=htons(56845), 
> sin_addr=inet_addr("127.0.0.1")}, [16]) = 0
>     Received event: "connection broken by remote peer
> 
> into this:
> 
>     recvfrom(5, "hello", 4096, 0, {sa_family=AF_INET, sin_port=htons(55486), 
> sin_addr=inet_addr("127.0.0.1")}, [16]) = 5
>     Received string (5): "hello"
>     recvfrom(5, "", 4096, 0, {sa_family=AF_INET, sin_port=htons(55486), 
> sin_addr=inet_addr("127.0.0.1")}, [16]) = 0
>     recvfrom(5, "world", 4096, 0, {sa_family=AF_INET, sin_port=htons(55486), 
> sin_addr=inet_addr("127.0.0.1")}, [16]) = 5
>     Received string (5): "world"
> 
> ie the UDP process is still running and can still receive messages

And no one could ever expect that?  IOW, is this behavior obviously
wrong?