Merge pull request #1 from maceip/address-pr-comments

Address pr comments

Author: maceip

.claude/settings.json

@@ -0,0 +1,6 @@
+{
+  "attribution": {
+    "commit": "",
+    "pr": ""
+  }
+}

ChangeLog.md

@@ -24,6 +24,8 @@ See docs/process.md for more on how version tagging works.
   API stub functions.  These stub functions where never designed to work under
   Wasm Workers, so its safer to error at link time if pthread APIs are used
   in Wasm Worker-based programs. (#26336)
+- SDL2 port updated to include stub functions for `SDL_hid_init()` and related
+  functions. (#26297)
 
 5.0.2 - 02/25/26
 ----------------
@@ -46,8 +48,6 @@ See docs/process.md for more on how version tagging works.
   C `bool` type rather than `int`.  For example `emscripten_proxy_sync` and
   `emscripten_is_main_runtime_thread`. (#26316)
 - SDL2 port updated from 2.32.8 to 2.32.10. (#26298)
-- SDL2 port updated to include stub functions for `SDL_hid_init()` and related
-  functions. (#26297)
 - The remaining launcher scripts (e.g. `emcc.bat`) were removed from the git
   repository.  These scripts are created by the `./bootstrap` script which
   must be run before the toolchain is usable (for folks using a git checkout of

site/source/docs/compiling/Deploying-Pages.rst

@@ -71,8 +71,6 @@ An inherent property of asm.js and WebAssembly applications is that they need a
 
 Because this memory allocation needs to be contiguous, it can happen that the user's browser process does have enough memory, but only the address space of the process is too fragmented, and there is not enough linear address space available to satisfy the allocation. To avoid this issue, the best practice is to allocate the ``WebAssembly.Memory`` object (``ArrayBuffer`` for asm.js) up front at the top of the main page, before any other allocations or page script load actions are done. This ensures that the allocation has best chances to succeed. See the fields ``Module['buffer']`` and ``Module['wasmMemory']`` for more information.
 
-Additionally, it is possible to opt in to content process isolation specifically for a web page that needs this kind of a large allocation. To utilize this machinery, specify the HTTP response header ``Large-Allocation: <MBytes>`` when serving the main html page. This support is currently implemented in Firefox 53.
-
 Last, it is easy to accidentally cling to large unneeded blocks of memory after the page has loaded. For example, in WebAssembly, once the WebAssembly Module has been instantiated to a ``WebAssembly.Instance`` object, the original ``WebAssembly.Module`` object is no longer needed in memory, and it is best to clear all references to it so that the garbage collector can reclaim it, because the Module object can be dozens of megabytes in size. Similar, make sure that all XHRed files, asset data and large scripts are not referenced anymore when not used. Check out the browser's memory profiling tool, and the ``about:memory`` page in Firefox to perform memory profiling to ensure that memory is not being wasted.
 
 Robust Error Handling
@@ -106,7 +104,7 @@ This way the page will be future compatible once support for the particular feat
 
 - Use a network limiter tool to constrain download or upload bandwidth speeds to simulate slow network connections. This can uncover bugs related to timing dependencies for network transfers. For example, a small network transfer may be implicitly assumed to finish before a large one, but that might not always be the case.
 
-- When developing the page locally, perform testing by using a local web server and not just via ``file://`` URLs. The script ``emrun.py`` in Emscripten source tree is designed to serve as an ad hoc web server for this purpose. Emrun is preconfigured to handle serving gzip compressed files (with suffix ``.gz``), and enables support for the ``Large-Allocation`` header, and allows command line automation runs of compiled pages.
+- When developing the page locally, perform testing by using a local web server and not just via ``file://`` URLs. The script ``emrun.py`` in Emscripten source tree is designed to serve as an ad hoc web server for this purpose. Emrun is preconfigured to handle serving gzip compressed files (with suffix ``.gz``), and allows command line automation runs of compiled pages.
 
 - Catch all exceptions that come from within entry points that call to compiled asm.js and WebAssembly code. There are three distinct exception classes that compiled code can throw:
 

site/source/docs/porting/networking.rst

@@ -96,3 +96,31 @@ Direct UDP communication is not available in browsers, but as a close
 alternative, the WebRTC specification provides a mechanism to perform UDP-like
 communication with WebRTC Data Channels. Currently Emscripten does not provide a
 C/C++ API for interacting with WebRTC.
+
+Direct Sockets API (Isolated Web Apps)
+=======================================
+
+The `Direct Sockets API <https://wicg.github.io/direct-sockets/>`_ provides
+real TCP and UDP socket access from the browser, without needing a proxy server.
+This API is only available inside Chrome Isolated Web Apps (IWAs).
+
+Emscripten can route POSIX socket syscalls through the Direct Sockets API using
+``TCPSocket``, ``TCPServerSocket``, and ``UDPSocket``. This enables existing
+C/C++ networking code (including libraries like OpenSSL and Tor) to work
+with real network sockets inside an IWA.
+
+To enable Direct Sockets support, compile and link with
+``-sDIRECT_SOCKETS``. This also requires ``-sASYNCIFY`` (or JSPI).
+
+The following POSIX socket functions are supported:
+ - ``socket()``, ``bind()``, ``connect()``, ``listen()``, ``accept()``,
+   ``send()``, ``recv()``, ``sendto()``, ``recvfrom()``, ``sendmsg()``,
+   ``recvmsg()``, ``shutdown()``, ``getsockname()``, ``getpeername()``,
+   ``setsockopt()``, ``getsockopt()``, ``poll()``, ``ioctl()``,
+   ``fcntl()``, ``pipe()``, ``socketpair()``
+
+WebTransport and QUIC
+=====================
+
+WebTransport may be used to send UDP like datagrams over QUIC.
+Currently Emscripten does not provide a C/C++ API for interacting with WebTransport.

src/lib/libbase64.js

@@ -8,18 +8,20 @@ addToLibrary({
   // Decodes a _known valid_ base64 string (without validation) and returns it as a new Uint8Array.
   // Benchmarked to be around 5x faster compared to a simple
   // "Uint8Array.from(atob(b64), c => c.charCodeAt(0))" (TODO: perhaps use this form in -Oz builds?)
+#if !JS_BASE64_API
   $base64Decode__postset: `
   // Precreate a reverse lookup table from chars
   // "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/" back to
   // bytes to make decoding fast.
-  for (var base64ReverseLookup = new Uint8Array(123/*'z'+1*/), i = 25; i >= 0; --i) {
-    base64ReverseLookup[48+i] = 52+i; // '0-9'
-    base64ReverseLookup[65+i] = i; // 'A-Z'
-    base64ReverseLookup[97+i] = 26+i; // 'a-z'
+  for (var base64ReverseLookup = new Uint8Array(123/*'z'+1*/), __b64i = 25; __b64i >= 0; --__b64i) {
+    base64ReverseLookup[48+__b64i] = 52+__b64i; // '0-9'
+    base64ReverseLookup[65+__b64i] = __b64i; // 'A-Z'
+    base64ReverseLookup[97+__b64i] = 26+__b64i; // 'a-z'
   }
   base64ReverseLookup[43] = 62; // '+'
   base64ReverseLookup[47] = 63; // '/'
 `,
+#endif
   $base64Decode__docs: '/** @noinline */',
   $base64Decode: (b64) => {
 #if JS_BASE64_API