| TIP: Click on subject to list as thread! | ANSI |
| echo: | |
|---|---|
| to: | |
| from: | |
| date: | |
| subject: | Correction to previous - ticket #9 stuff |
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) SEEN-BY: 19/33 34/999 90/1 116/18 123/500 128/187 140/1 218/700 230/150 SEEN-BY: 240/1120 249/303 250/1 261/38 100 266/404 267/155 280/464 282/1031 SEEN-BY: 282/1056 292/907 908 320/119 219 340/400 393/68 396/45 633/267 280 SEEN-BY: 640/384 712/620 848 770/1 801/161 189 2320/100 @PATH: 123/500 261/38 712/848 633/267 |
|
| SOURCE: echomail via fidonet.ozzmosis.com | |
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™.