Ticket #553 (Invalid)Tue Aug 16 07:17:50 UTC 2022
Incompatibility between the TCP-IP/Beta1 and the ROD Resolver.
| Reported by: | André Timmermans (100) | Severity: | Normal |
| Part: | RISC OS: Software library | Release: | |
| Milestone: | Status | Invalid |
Details by André Timmermans (100):
See https://www.riscosopen.org/forum/forums/8/topic…
ROD Resolver_GetAddrInfoAsync seems to follow the classical Linux format:
struct addrinfo {
int ai_flags;
int ai_family;
int ai_socktype;
int ai_protocol;
socklen_t ai_addrlen;
struct sockaddr *ai_addr;
char *ai_canonname;
struct addrinfo *ai_next;
};
in the TCP-IPBeta1, the the order of elements ai_addr and ai_canonname are inversed.
Changelog:
Modified by Sprow (202) Sat, August 27 2022 - 08:34:56 GMT
- Status changed from Open to Invalid
- Part changed from Unspecified to RISC OS: Software library
I think when Rick said “Have you raised a bug report?” he meant with ROD.
The TCPIPLibs are correct, the order matches the RFC2553 (added to RISC OS in 2018) and FreeBSD (from which the network stack is derived), so nothing to do here.
Modified by André Timmermans (100) Thu, September 29 2022 - 16:34:13 GMT
- Status changed from Invalid to Open
I add also filed a ticket on the ROD side and from the ROD side:
“We’ve used the generally accepted linux/BSD layout for the structure and moving things around means more complications when porting things.”
So for god’s sake, enough bickering both sides should talk to each other. I don’t want to see another RISC OS versions war!
Modified by Sprow (202) Wed, November 02 2022 - 18:13:31 GMT
For my personal amusement I looked at our contemporaries:
NetBSD
http://cvsweb.netbsd.org/bsdweb.cgi/src/include…
line 200 http://cvsweb.netbsd.org/bsdweb.cgi/src/include…/x-cvsweb-markup
FreeBSD
https://svnweb.freebsd.org/base/stable/12/inclu…
line 135 https://svnweb.freebsd.org/base/stable/12/inclu…
DragonflyBSD
https://gitweb.dragonflybsd.org/dragonfly.git/h…
line 136 https://gitweb.dragonflybsd.org/dragonfly.git/h…
Microsoft Windows
Windows uses winsock, so the addrinfo struct is in <ws2def.h>
https://learn.microsoft.com/en-us/windows/win32…
line 899 https://github.com/tpn/winsdk-10/blob/master/In…
RISC OS
RISC OS added RFC2553 support in 2018
https://gitlab.riscosopen.org/RiscOS/Sources/Li…
line 114 https://gitlab.riscosopen.org/RiscOS/Sources/Li…
QNX
https://www.qnx.com/developers/docs/7.1/#com.qnx.doc.neutrino.lib_ref/topic/a/addrinfo.html
Apple
https://opensource.apple.com/source/Libinfo/Lib…
Going back to the subject of your ticket – the resolver you tested with is binary incompatible, hence nothing to do here: the TCPIPLibs match themselves already. Porting is no easier or harder using the RFC2553 ordering since the C compiler matches by name, so mystruct->member in the ported code would be placed at whatever offset the header file listed it at when compiled.
Modified by Sprow (202) Sun, December 18 2022 - 15:29:53 GMT
- Status changed from Open to Invalid
