Hello Eric, > Hi guys, interesting anecdote from Pat, but:
yes, it was interesting to see Pat watching this list at all. and while I agree completely with what he wrote, IMO he slightly missed the point (and you -eric- miss it completely) > The whole point is that if you remove the break; completely, then > somebody who later reads or changes the code might be mislead into > thinking that the code SHOULD fall through ... the whole point is that in a shared programming effort (as the freedos kernel still should be) it's a waste of resources to change ANYTHING without a certain payback. in this case, removing 'break;' may have saved 5 bytes in the early 90ties, but is irrelevant (or even contraproductive) with optimizing compilers, and leads only to such irrelevant 'why was this changed' threads. even if this WOULD save 3,5, or even 10 byte: it's completly irrelevant. the kernel has more then enough space in HMA, >= 40 buffers ARE enough, and fighting lengthy email threads to free possibly another 512 byte (with exactly zero performance increase) is simply a waste of developers time, ethernet and my barins bandwidth. Besides that, this byte fiddeling attitude is the IMO the reason for the developement kernels name - 'unstable'. tom > after the return_user, > or that it would be OKAY to fall through - in both cases, he will > either not UNDERSTAND the code properly or will even add BUGS by > erroneously adding the possibility of returning to the caller to > return_user(). > So: OKAY, remove break; if you want, BUT add a comment instead of the > break;, to let people know that return_user() never returns. You should > even add such a comment to return_user() itself actually. > By the way, you probably save even more bytes - and a bit of stack > space - by using an evil GOTO for the return_user(), unless it already > is an inlined macro or similar already anyway. > OLD: break; > BAD: (nothing) > BETTER: /* return_user never returns, no break needed */ > EVIL: use goto instead of call for return_user ;-). > Eric > PS: Which kernels contain the DOSLFN compatibility patch (improved > xBPB/DPB initialization and set extended error code implemented), > did somebody contact GRUB people about 0.0.35 vs. 1.0.35 version ID, > does anybody remember why FreeCOM has "if XMS swap version, then > disable LOADFIX" in #if, and why old CATS of HTMLHELP required LOADFIX > to work with DOS=HIGH (I seem to remember that recompiling with either > Toms or my KITTEN version or recompiling ZLIB or both was what Bob did > to fix the bug... maybe there are OTHER programs with CATS affected? > Which programs still use CATS instead of KITTEN? Symptom was a CRASH > when using HTMLHELP several times on SOME systems if DOS=HIGH...) ...? > And did Arkady re-add the seemingly but not actually unneeded BPB/... > initialization at boot time which he had removed at some point? > ------------------------------------------------------- > The SF.Net email is sponsored by: Beat the post-holiday blues > Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. > It's fun and FREE -- well, > almost....http://www.thinkgeek.com/sfshirt > _______________________________________________ > Freedos-kernel mailing list > Freedos-kernel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-kernel -- Kind regards, Tom Ehlert mailto:[EMAIL PROTECTED] +49-241-79886 ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
