home bbs files messages ]

Just a sample of the Echomail archive

Cooperative anarchy at its finest, still active today. Darkrealms is the Zone 1 Hub.

   SYNC_SYSOPS      Synchronet Multinode BBS Software Suppor      33,243 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 30,277 of 33,243   
   echicken to GitLab note in main/sbbs   
   Shroedinger's Variable?   
   06 Sep 24 21:46:56   
   
   TZUTC: -0700   
   MSGID: 56254.sync_sys@1:103/705 2b41ec7e   
   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_5571   
      
   I looked through some old commits and found [this](https://gitla   
   .synchro.net/main/sbbs/-/merge_requests/237#note_2998), which is where I   
   encountered and worked around a similar issue.   
      
   Looking at the two commits there, it seems that maybe:   
   - computing an array index inside the accessor is sometimes problematic?   
   (`array[somevalue + someothervalue]`)   
   - introducing a situation where the dynamic index value might be coerced to   
   string / passed into log() will make it become real?   
      
   You might try changing:   
      
   ```js   
                               if (FFrameMasked) InByte ^= FFrameMa   
   k[FFramePayloadReceived++ % 4];   
   ```   
      
   to   
      
   ```js   
                               var idx = FFramePayloadReceived++ % 4;   
                               if (FFrameMasked) InByte ^= FFrameMask[idx];   
   ```   
      
   or even   
      
   ```js   
                               var idx = FFramePayloadReceived++ % 4;   
                               if (idx < 0 || idx >= 4) log(LOG_DEBUG, 'This will   
   never happen');   
                               if (FFrameMasked) InByte ^= FFrameMask[idx];   
   ```   
      
   which seems similar to what I ended up doing. Which of course would be a   
   workaround but I wonder if either of those would "solve" the problem.   
      
   Regarding JS runtime behavior, it's wild speculation on my part. I remember   
   seeing discussion within the past few years of what I think were compile-time   
   options for SpiderMonkey and something in that is nagging at me, like this   
   could be a symptom of some JS optimization gone wrong.   
   --- SBBSecho 3.20-Linux   
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)   
   SEEN-BY: 90/1 103/705 105/81 106/201 124/5016 153/757 7715 154/10   
   SEEN-BY: 154/30 203/0 218/700 221/0 226/30 227/114 229/110 114 206   
   SEEN-BY: 229/317 400 426 428 470 550 700 705 240/1120 5832 266/512   
   SEEN-BY: 280/464 5003 282/1038 291/111 292/8125 301/1 320/219 322/757   
   SEEN-BY: 341/66 234 342/200 396/45 423/120 460/58 256 1124 467/888   
   SEEN-BY: 633/280 712/848 770/1 5020/400 5054/30 5075/35   
   PATH: 103/705 280/464 460/58 229/426   
      

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca