TIP: Click on subject to list as thread! ANSI
echo: mbse
to: ALL
from: SAMPSA LAINE
date: 2016-10-29 22:54:00
subject: Correction to previous -

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)

SOURCE: echomail via QWK@docsplace.org

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.