对于C语言，内存分配是非常重要的，这涉及到程序的稳定性和安全性。假设有在stack中存储username和pw这样安全敏感的数据，有风险，因为函数返回时，这些内容并没有真正消失，如果是我们自己的程序，确保只有我们自己的代码访问内存没有问题，但是如果是合作性的或者是库方式，有buffer overflow exploit的隐患。例如，通过memcpy覆盖函数的返回地址（存放在stack），可以跳到hacker代码的入口。因此我们要注意检测数据的边界，不允许越界处理，另外这类数据可采用heap的存放方式，自主控制分配和释放（stack的是由系统自动进行）。此外我们要避免将某些敏感数值，例如pw写死，作为initialized data，相对地址和数值固定不变，存在风险，可以通过gdb或者某些方式来获取。在java，不会出现这种情况，所有内存分配和释放都是系统进行。
2.创建自定义装饰器，用于在控件的四个角上显示红线
介绍单链表的增、删处理。
那么是否能自定义一个AdornerDecorator来实现AdornerLayer呢？答案是肯定的。但是就必须写成：
注意：<TextBox Grid.Row="0" Grid.Column="1" m:AdornerDecoratorHelper.AdornerLayer="{Binding ElementName=grid}" />
AdornerDecoratorHelper.AdornerLayer是我定义的附加属性，附加属性中指定了一个grid对象，目的是用grid的默认AdornerLayer，在器上面添加自定义装饰器（控件周围的红线）。
4.辅助的样式，为了美观，在App中定义一些默认样式
sscanf，语法和printf相似，但是不是写，而是从中读取。例如sscanf(line," %d %c",&n,&c);则根据格式，将line的相应内容读入n和c中，返回读取的内容，如果line="123"，则只能读取%d到n，1个数据，返回1，如果line"123X"，则读取两个数据，返回2。scanf是从keyborad中读取，同理。
- 2011.10.30
上次的思路是遍历窗体中的控件，如果是指定类型则使用自定义的装饰器。但是如果要求部分控件使用自定义装饰器，或者用户控件中的控件也要实现，上一种方法是无法完成的。
思路：
1.定义一个自定义AdornerDecorator，用于为控件创建一个AdornerLayer；
2.在AdornerLayer上定义自定义的装饰器样式
代码比较简单，见注释说明。
实现步骤：
1.创建自定义AdornerDecorator类，AdornerDecoratorHelper
看看效果吧：
typedef struct node{
int n;
struct node * next;
}t_node;
3.窗体实现
介绍数组。数组预先限定大小，允许分配某个固定值，都可能产生越界。采用realloc可以解决，但是效率较低。接着介绍单链表。
我在上一篇博文中介绍了如何使用自定义装饰器实现SAP的焦点样式。
有一个以前没用过的空间分配函数 realloc()，就是重新分配的意思，可以用了扩大内存大小，而不影响原有的数据。realloc实际调用malloc，并将原来的内容memcopy过来，free原来的内容。
相关链接：
文件存放采用类似的方式，通过增加block来增加存储空间。利用此，我们可以获取或猜测已删除文件的的地址，并进行恢复。例如加入一个文件，可以从文件读取前前面地址存放的数据。具体和disk文件架构相关。
