#1764 .StreamSocket~new fails on Linux (Ubuntu and Mint at least)

[Ruurd Idenburg]

The failure is only detected after the '0D0A'x glitch has been bypased. On my Linux system the socket is created successfully but the "errno" is set to a failure (always 29) in my case, causing the private ' rcvbuf' attribute not to be initialized as a mutable buffer, which will cause failures to receive data via 'linein' later on. I've looked at the C++ code behind the socket implementation, but I am not savvy enough to isolate the cause of the problem. I don't know if Windows and/or MacOS have the problem also, because I am using Linux exclusively.

Problem can be reproduced with the attached piece of code

[Ruurd Idenburg]

Problem can be bypassed by subclassing and using something similar as follows in the 'init' method

::method init
forward class(super) continue
self~rcvbuf = .mutablebuffer~new(, self~bufsize)

[Erich]

Duplicate [bugs:#1763]

[Anonymous]

I don't think it is a duplicate. I did some further investigation into the closeness of socket and streamsocket. Streamsocket is invoking .socket~new and then checks the errno. In the past (I'm talking 2018) .socket~init would check the return from the SockSocket create call for less than 0 and if not negative set errno to the empty string. That has been changed some time since , because the return from SockSocket is not checked anymore and leaves errno untouched.

[Ruurd Idenburg]

In fact the change was in commit R11516 on 2018/11/06. So if the socket class isn't checking the reurn anymore, why would the streamsocket class have to do it still?

[Erich]

Ruurd, I just did a fresh commit intended to fix the errno issue - see [bugs:#1763]
I'll fix all Socket/StreamSocket issues - I just want to run this as a single bug.

[Ruurd Idenburg]

That is Ok Erich, just wanted to make sure that the problem was recognized, Appreciate all your efforts.