Hi Guys,   
      
   First of all, let me say that I'm a HUGE fan of MBSE, have been for literally   
   for almost as long as I've been playing with UNIX BBSing (early 90s onwards).   
      
   Anyway, I posted a bug report a while ago and was wondering if anyone   
   actually   
   took a look at it?   
      
   TL;DWR: The bug is at https://sourceforge.net/p/mbsebbs/tickets/9/ (ticket   
   #9,   
   damn it, I WANTED A PRIME NUMBER :P) and my more indepth explanatin of the    
   problems I encountered are here:     
      
   Not sure if you guys still read this echo but I'm running MBSE 1.0.6 and I   
   can across a few bug and ssome minor inconveniences in the compilation   
   process,    
   mainly:   
      
   I.  There are some places in the code where a pointer is case to an int.   
       This DOES NOT work on certain platform, zLinux being one of them with   
       32-bit ints and 64-bit pointer.    
          
       For example, this is potentially dangerous:   
          
       filelist.c:496:3: warning: cast from pointer to integer of different size   
   \   
      [-Wpointer-to-int-cast (unsigned int)tmpf->flofp, (unsigned   
   int)tmpf->floff);   
      
       Luckily there are only TWO of these bugs in the whole codebase, maybe   
   some   
       leftover from the everything-is-32-bit era?   
      
   II. If certain #ifdefs do not recognise the CPU, naturally the code  doesn't    
   know to call it and what the signal names on that platform are. IMHO this   
   could be solved by either:   
          
       - Having an #elseif, throwing a #warning about unsupported CPU and   
   setting   
         the signal name array to some sensible default (I used x86, have no   
   issues)   
      
                                       OR   
      
       - Passing in a -DCPU_OVERRIDE_ID="FooProc" and   
   -DUSE_SIGNALS="SomeOtherCpu",   
         and instructing the user todo this.   
      
      
   My suggestions as to fixes?   
      
   I.  Never cast a pointer to an int or vice versa. This occurrs exactly TWICE   
       in your code base, filelist.c:496 and ftn2rfc.c:308 so not a huge fix I   
       think.   
      
   II. Dropping necessary(IMHO) #error's if the CPU is "not one of the above"   
      
   In a number of places, the code does a #ifdef to determne the CPU type and   
   whilst I'm impressed by the number of platform supported IBM S/390 and/or   
   z/Series aren't represented (not that I'm surprised, I'm probably the only   
   person in the world running MBSE on any kind of zLinux.   
      
   Anyway instead of #error'ing out of the whole compile, I changed the bits   
   which are CPU sensitive to instead throw a #warn "Unknown CPU, assuming IBM   
   S/390" [of course this should probablysay some differnet].   
      
   So from lib/strutil.c:399:2: error: #error "Unknown CPU" I do:   
      
   File: lib/strutil.c, starting at line 398>   
      
   398: #else   
   399: #warning "Unknown CPU - defaulting to IBM S/390"   
   400:     return (char *)"IBM S/390";   
   401: #endif   
   402: }   
      
   I did these/similar changes to these files:   
      
       lib/signame.c   
       lib/strutil.c   
       mbmon/mbmon.c   
       mbtask/signame.c   
      
   (I just used the signal name array for x86, not ideal but I really didn't   
   have the time to look up the exact Debian/s390x versions - this shouldn't be   
   too strenuous)   
      
   Again you could do this with a -DCPU_OVERRIDE_ID="FooProc" type flag if you   
   don't think an #elseif is a good idea.   
      
   Conclusion   
   ----------   
      
   On the plus side, I've been running MBSE 1.0.6 on Debian/s390x for months at   
   a time without a problem, so nothing too vital seems to be broken.   
      
   I would however suggest that you look into those void*<->int casts because   
   that could break on other platforms as well..   
   --- SBBSecho 2.27-Win32   
    * Origin: B4BBS = London = b4bbs.sampsa.com 2:250/7 (2:250/7)