REPLY: 3:633/267 618df19c   
   MSGID: 2:463/68 61917255   
   CHRS: CP1125 2   
   TZUTC: 0200   
   TID: hpt 1.3.0/lnx 17-09-02   
   Hi andrew!   
      
   12 Nov 21, andrew clarke ==> Dallas Hinton:   
      
    DH>> Binkd on Windows 10 32-bit. Is there a way to block a particular node   
    DH>> from doing a file request? I've one node who keeps requesting a packet   
    DH>> (that doesn't exist) and that causes Binkd to crash! :-(   
      
    DH>> + 11 Nov 15:20:41 [1980] pwd protected session (MD5)   
    DH>> + 11 Nov 15:20:41 [1980] sending c:\OUTBOUND\000f1d91.th0 as   
    DH>> 000f1d91.th0 (165816) - 11 Nov 15:20:41 [1980] receiving 61e1ed3d.pkt   
    DH>> (186 byte(s), off 0) ? 11 Nov 15:20:41 [1980] GET: remote requests   
    DH>> seeking 000f1d91.th0 to 180224, file size I64u   
      
    ac> I suspect turning off logging temporarily will prevent the crash.   
      
    ac> ...   
      
    ac> I don't have time to send a pull request, but for other developers   
   reading this:   
      
    ac> "I64u" is a printf-formatting bug. It should be "%I64u", which gets   
   converted to the file size at runtime.   
      
    ac> diff for protocol.c:   
      
    ac> -        Log (1, "GET: remote requests seeking %s to %" PRIuMAX ", file   
   size " PRIuMAX,   
    ac> +        Log (1, "GET: remote requests seeking %s to %" PRIuMAX ", file   
   size %" PRIuMAX,   
    ac>               argv[0], (uintmax_t) offset, (uintmax_t) state->out.size);   
    ac> -        msg_sendf(state, M_ERR, "Invalid M_GET violates binkp: offset "   
   PRIuMAX " after end of file, file %s size " PRIuMAX,   
    ac> +        msg_sendf(state, M_ERR, "Invalid M_GET violates binkp: offset %"   
   PRIuMAX " after end of file, file %s size %" PRIuMAX,   
      
   Many thanks! The patch was applied.   
      
    ac> Though this isn't the only place in the binkd code where this bug exists.   
      
    ac> Obviously checking whether PRIuMAX is prefixed with "%" in every call to   
   Log() or msg_sendf() etc is visually difficult and error-prone.   
      
    ac> This should instead be fixed at the source, in sys.h:   
      
    ac> -  #define PRIdMAX "I64i"   
    ac> -  #define PRIuMAX "I64u"   
    ac> +  #define PRIdMAX "%I64i"   
    ac> +  #define PRIuMAX "%I64u"   
      
    ac> Then change the .c files that reference these macros accordingly.   
      
   This way was choosen due to use of the format "%8" PRIuMAX in ftnq.c.   
   I'm not sure is it better to create another macro PRIuMAX8 or keep existing   
   PRIdMAX without '%'.   
      
                 Lucky carrier,   
                              Pavel   
                              aka  gul@gul.kiev.ua   
   --- GoldED+/LNX 1.1.5-b20160827   
    * Origin: II:CDLXIII/LXVIII (2:463/68)   
   SEEN-BY: 1/123 14/0 90/1 103/705 105/81 114/709 120/340 123/131 124/5016   
   SEEN-BY: 129/305 153/757 154/10 203/0 221/0 226/30 227/114 229/200   
   SEEN-BY: 229/424 426 550 664 700 240/2100 5138 5411 5824 5832 5853   
   SEEN-BY: 240/6309 249/109 206 307 317 280/464 5003 5555 282/1038 292/854   
   SEEN-BY: 292/8125 301/1 310/31 320/219 322/757 341/234 342/200 396/45   
   SEEN-BY: 423/120 460/16 58 256 1124 5858 463/68 1331 467/4 633/280   
   SEEN-BY: 712/848 770/1 2432/390 2452/250 2454/119 5020/1042 5054/30   
   PATH: 463/68 460/58 280/464 240/5832 229/426