TZUTC: -0700   
   MSGID: 56292.sync_sys@1:103/705 2b455daa   
   PID: Synchronet 3.20a-Linux master/e93b6dfa6 Aug 22 202 GCC 12.2.0   
   TID: SBBSecho 3.20-Linux master/984c371ae Sep 06 2024 20:48 GCC 12.2.0   
   BBSID: VERT   
   CHRS: ASCII 1   
   https://gitlab.synchro.net/main/sbbs/-/issues/782#note_5597   
      
   Replacing the hardcoded 'undefined' in the `log` call with a variable didn't   
   help.  No matter what I try, if I conditionally call `log` the input is   
   garbled.  The only thing that works is unconditionally calling `log` for every   
   byte.   
      
   I was curious why the conditional call fixed things for you in `randomString`   
   but not for me, and after investigating it looks like it didn't, at least not   
   fully.  When I checked my 0001.web file I found:   
      
   `csrf_token=8EMorJ4QundefinedKundefinedundefinedundefinedundefin   
   dundefinedg2mBMKfpagGBuOm2oOveEShPThIs`   
      
   So it looks like calling `log` for the impossible numbers eventually allows it   
   to recover and start generating valid numbers again, but there's still a   
   stretch of impossible numbers in there as well.   
      
   If I alter `randomString` to unconditionally call `log`, then a good   
   `csrf_token` is generated.   
      
   Going back to the websocket unmasking, I found multiple function calls that   
   workaround the bug.  For example `mswait(InByte / InByte)` works, but would   
   introduce undesirable delays when uploading files.  `ascii` seems to be the   
   most promising, since `Result += ascii(InByte)` is equivalent to the existing   
   `Result += String.fromCharCode(InByte)`, so is a drop-in replacement (at least   
   as far as I can tell).   
      
   And `randomString` could be refactored to use `ascii` as well.  Drop the   
   `.split("")` to keep `chars` as a string, then change `str += chars[rn]` to   
   `str += ascii(ascii(chars[rn]))`, and while super-janky to double-call `ascii`   
   like that, it results in a random string without any 'undefined' bits.    
   Alternatively you could switch from a for loop to a while loop, and put the   
   `str += chars[rn]` portion into an else so it only appends when `chars[rn]` is   
   defined.   
      
   Speaking of while loop, I checked to see whether it would have the same issue   
   as the for loop, and it does.  Then I manually unrolled the for loop, and it   
   worked fine.  So definitely seems to be related to loop optimization going   
   haywire.   
   --- SBBSecho 3.20-Linux   
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)   
   SEEN-BY: 10/0 1 90/1 102/401 103/1 17 705 105/81 106/201 124/5016   
   SEEN-BY: 153/7715 214/22 218/0 1 215 601 700 720 840 860 870 880 930   
   SEEN-BY: 226/30 227/114 229/110 114 206 317 400 426 428 470 550 700   
   SEEN-BY: 229/705 266/512 280/464 282/1038 291/111 301/1 320/219 322/757   
   SEEN-BY: 342/200 396/45 460/58 633/280 712/848 5075/35   
   PATH: 103/705 218/700 229/426