NO_XSLOCKS shouldn’t affect htons() et al. (Or should it?)

[FGasper]

Description Earlier today I discovered that XSUB.h overwrites functions like htons. With Leon’s help I learned that it has to do with the implicit-sys logic, which itself depends on NO_XSLOCKS being undefined. While perlguts discusses NO_XSLOCKS, it makes no mention of its role vis-à-vis implicit-sys.

The overwrite is problematic because Perl’s versions of these functions require the thread-context local variable (aTHX), which means C functions that lack that local variable will break when calling these. For example:

static int _my_htons(int myint) {
    return htons(myint);
}

/* Then, later … */

int
do_htons(SV* somenum)
    CODE:
        UV mynum = SvUV(somenum);
        RETVAL _my_htons((int) mynum);
    OUTPUT:
        RETVAL
}

The overwrite’s rationale of things like open, per Leon, is that it allows different Perl interpreters to implement those differently. The problems are:

• It’s undocumented, as far as I can tell.
• It’s unclear—even to Leon—why pure functions like htons are overwritten.

This case documents:

1. Adding documentation about all of this. (#19572 will implement that.)
2. Possibly paring back the list of functions that XSUB.h overwrites with context-requiring macros. (Or, if there’s a legit reason for htons & co. to be overwritten, discuss that in the added documentation.)

---

So … should things like htons be overwritten? If not, this issue is to track that.

[bulk88]

I agree perlhost.h is too aggressive. Without using git blame, I can guess a few reasons why it was hooked.

1. Attempt to emulate a big endian CPU OS on Win32/maybe linux. So "host" ints written to disk are opposite of real "host".
2. What is a "network address"? And think back to 1990. Perhaps its 16 bits, or 48 bits, or 36 bits. IPv4/IPv6 are an accident of history. They violate the OSI commission. And all nations except the USA agreed X.25 packet switching, with E.164 phone number cough cough "addresses" (+011-etc), was the future. Continuing the work, of 100 years of "National Post and Telegraph" legislation, diplomacy, and bureaucracy. Not 1 man in California with a Xerox machine and stamps controlling the world.
3. On Win32 perl, ntohs(), etc, are implemented by calling the ntohs() etc symbols in "ws2_32.dll" aka "Winsock", not in libc (aka kernel32.dll/msvcrt.dll). A long time ago, Win16 era definitely, maybe NT 3.51 or 3.5, winsock was a non-MS 3rd party paid software app as an upgrade to your OS. MS eventually bought that company or wrote their own lib and bankrupted that 3rd party. So ancient history, Perl had to deal with PCs with a missing/no sockets library DLL (or not, perlhost.h is 1997 ish code IIRC). Or random 3rd party sockets libraries that were commercial competitors.
4. Maybe on some OSes/protocols stacks/ethernet cards/C structs, for convenience the address and port bytes are already flipped around at a hardware/kernel layer to LE. And P5P/some perl core dev thought, dynamic NOOPing the byteswap functions will be needed to maintain POSIX portability.

Question, did any Unix libc ever dynamically change the behavior of htonl() or ntohl() , like if you made a socket with AF_BURROUGHS or AF_IBMSYS390 exotic proprietary mainframe protocols, suddenly the LE/BE logic table changed?

Also remember 1s complement CPUs exist, not sure if Perl 1-5 was ever compatible.

IMO the hooks and an exported Perl C function, can stay, because P5's implementation can be more efficient (CPU intrinsic 1 op) vs the OS (i386 and we mean it). Or in Win32 Perl's case, not current code base, but if I repair WIN32_NO_SOCKETS or do a sockets delay load DLL optimization.

Then Perl_htonl() is much "more efficient" since calling that alone, will not load winsock.dll into the process (very short runtime life scripts). Compared to Win32 native os htonl() func symbol. Why this a LINKED EXPORTED ABI C fn call in 2024, when BYTESWAP has been a x86 CPU intrinsic for decades https://www.felixcloutier.com/x86/bswap, another ticket, another day.

Other OSes, maybe some kind of 16 vs 32 vs 64b problem with the OS. My opinion, requiring pTHX? That can absolutely can be removed. Worst case, a "bug fix" is max 12 months away until next major Perl release.

[Leont]

My opinion, requiring pTHX? That can absolutely can be removed. Worst case, a "bug fix" is max 12 months away until next major Perl release.

That's because of IMPLICIT_SYS on Windows.