[[ blog 이사 과정에서 정확한 posting날짜가 분실됨. 년도와 분기 정도는 맞지 않을까? ]]

ActivitySmall Project
(2,500 lines of code)
Large Project
(500,000 lines of code)
Architecture/design10% 30%
Detailed design20% 20%
Code/Debug25% 10%
Unit test20% 5%
Integration15% 20%
System test10% 15%

< Source : Adapted from Code Complete (McConnell 1993) >

[[ blog 이사 과정에서 정확한 posting날짜가 분실됨. 년도와 분기 정도는 맞지 않을까? ]]

Ascending Stack : The stack grows upwards, starting from a low address and progressing to a higher address.
Descending Stack : The stack grows downwards, starting with a high address and progressing to a lower one.

Fundamentally, these two are same. But, I prefer descending stack, because when stack is broken, mostly post-stack-section(higher memory address) tends to be broken. So,

- [case1 : current stack has enough free space]
Descending stack is better to detect stack-corruption than ascending stack.

void func_test(void)
{
    (omitted...)
    char a[10]; // ---(*1)
    (omitted...)
    memcpy(a, data, len); // len > 10 ---(*2)
   (omitted...)
}

If stack space after (*1) is not used, then even if stack is corrupted, it is very difficult to detect in ascending stack.
(because, no one uses corrupted area.) So, debugging is more difficult.

- [case2 : current stack is almost pull]
In descending stack, usually, corrupting stack of specific thread(Thread A) affects it's own behavior firstly. So, it is easier to debug - same with [case1].
In ascending stack, corrupting stack may affects to other thread's stack - thread whose stack is just next (higher address) of Thread A - firstly with high possibility (especially, if several stacks are adjacent in memory space). This usually leads to debugging-nightmare

'Study > Computer Science' 카테고리의 다른 글

[Study] Understanding XOR operation  (0) 2008.07.07
[Study] Full Stack Vs. Empty Stack  (0) 2007.01.08

[[ blog 이사 과정에서 정확한 posting날짜가 분실됨. 년도와 분기 정도는 맞지 않을까? ]]
 

It's very famous issue. That's why using floating point operation is difficult.
Especially, round-off can make up to 0.5f erratum.
In calculation for drawing on pixels, round-off is frequently used - Do not consider blending and anti-aliasing. And even sum of two errata can make 1 pixel erratum. So, we should always keep this in mind when implement pixel-relative-calculation.

Here is example.

Line L passes point P0 and P1.
Drawing two lines those are orthogonal to L, L-symmetric, passes point P2, P3 respectively and length is R.

As you know, there two lines should be parallel.
But, in this case, we should calculate two end points - the results may be float type. To draw this we should make those as an integer value (usually by using round-off).
For each line, up to 0.5f erratum can exist. So, for two lines, up to 1 pixel erratum can be raised. So, when these two lines are drawn on the canvas, they may not be parallel.

'Domain > Software' 카테고리의 다른 글

[GNU] Issues of cross-compiling in GNU build system.  (0) 2011.04.21
[Tips] Cyclic Queue  (0) 2010.10.18
[SW] Questions to evaluate SW Engineer  (0) 2009.04.09
[Prog] Using so-called 'context' data structure.  (0) 2008.01.10
[Spec] DWARF2  (0) 2006.08.30

+ Recent posts