Hi!
16-Мар-2005 08:11 [EMAIL PROTECTED] (Kenneth J. Davis) wrote to
[email protected]:
>> But adding things, which eases following fixes (and not breaks anything
>> already existing) - what bad in this?
KJD> I did not say there was something bad, what I said was that my commit
KJD> was to fix specific issues and at the time I did not want to commit
KJD> anything else. I personally like cvs log and try to commit things in
KJD> chunks so the log and diff are easy to follow for future references.
But if/when later if commit discussed macro, there will be required to
commit additional changes, which will reintroduce macro usage.
>> But this (manual macro expanding) introduces more differences (in
>> source and code) between different branches.
KJD> this manual macro expanding is what I do mentally when I see the macro;
KJD> I was not referring to actually manually expanding the line in the source
Macro is same thing, as function - (more or less) incapsulated piece of
code. And its issues (in this area of readability) are the same - if you use
bad/misleading names (like lpMyBeuatifulAndVeryNiceBufferDontKnowForWhat,
brk() or LAST_FIT_U), then you will be forced to restudy function/macro
functionality each time, when meet function/macro usage. But if function
name reflect functionality, then there will not be _need_ to restudy (or
study at all) function body. I hope, names "loword" and "hiword"
sufficiently consistent in this sense, also as "memcpy".
PS: There is recommended to split bug chunks of code by (relatively) small
and independent functions. One reason - for small pieces of code easier make
consistent, readable name, which reflects functionality.
PPS: Some my previous patches was relate to variables renaming and adding
another names. Without this, there is wrong names usage. Example:
tmpmode & (FIRST_FIT_UO | FIRST_FIT_U)
It should be: "tmpmode & HIGH_MASK" (where Lucho later rename HIGH_MASK to
FIT_U_MASK). See the differences: FIRST_FIT_* are _values_, but above used
as _mask_. The more so, there not need any FIRST_FIT_* at all - you may
combine FIRST_FIR, LAST_FIT and BEST_FIT with ALLOC_HIGH and ALLOC_HIGH_LOW
(for example, "BEST_FIT+ALLOC_HIGH"), check
if ((mode & FIT_MASK) == FIRST_FIT)
instead
case FIRST_FIT:
case FIRST_FIT_U:
case FIRST_FIT_UO:
or use
if ((mode & FIT_MASK) == LAST_FIT)
if (mode != LARGEST && (mode & ALLOC_HIGH_LOW) &&
mem_access_mode &= ~ALLOC_HIGH_LOW;
mem_access_mode = (mem_access_mode & ~HIGH_MASK) + ALLOC_HIGH;
instead
if ((mode == LAST_FIT) || (mode == LAST_FIT_UO) || (mode == LAST_FIT_U))
if ((mode != LARGEST) && (mode & FIRST_FIT_U) &&
mem_access_mode &= ~0x80;
mem_access_mode &= ~0x80; mem_access_mode |= 0x40;
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&op=click
_______________________________________________
Freedos-kernel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
