Hello Tom, Eric,
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'.
This particular issue is small, but it is mentioned for a reason. The reason probably being that a bigger design decision isn't actively known . . . Is the offical FreeDOS kernel only intended for PC use, or also for embedded small devices?
If it is only for PC use, then it doesn't matter, and it should be kept as easy to understand/debug as possible.
If use in embedded small devices is also the target, saving every byte often counts. In that case, add a compiler conditional, perhaps named OptimizeForSize or SaveEveryByte, and make the inclusion of the BREAK conditional. And, to avoid hurting the code readability, put that conditional in a macro that will be used wherever similiar tradeoffs are made.
OmmitIfOptimizeSize break ();
Peter
------------------------------------------------------- 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
