需要避免的MYSQL客户机程式设计错误

本文讨论一些常见的MySQLC API 程式设计错误，连同如何避免其发生（这些问题在MySQL邮件清单中会周期性地突然出现）。

1. 错误1——使用未初始化的连接处理程式指针

我们已通过传递NULL 参数调用了mysql_ i n i t ( )，这就是让他分配并且初始化MYSQL 结构，然后返回一个指针。另外一种方法是将指针传递到一个已有的MYSQL 结构中。在这种情况下， mysql_init() 会将结构初始化并返回一个指针，而不必自己分配结构。假如要使用第二种方法，则要小心会出现一些微妙的问题。下面的讨论指出了需要注意的一些问题。假如将一个指针传递给mysql_ init( )，他应该实际指向某些东西。看下面的代码段：



这个问题是，mysql_init() 得到了一个指针，但指针没有指向所知的任何地方。conn 是个局部变量，因此在main() 开始执行时他是个能指向任何地方的未初始化的存储器，这就是说mysql_init() 将使用指针，并可在内存的一些任意区域滥写。假如幸运的话， conn 将指向您的程式地址空间的外部，这样，系统将立即终止，使您能尽早意识到代码中出现的问题。

假如不幸的话， conn 将指向程式中以后才使用的一些数据的内部，直到再次使用那个数据时才发现问题。因此实际出现问题的地方远比执行程式时出现的问题多，也更难捕获到。下面是一段有问题的代码：



此时， conn 是个全局变量，因此在程式启动前，将他初始化为0（就是NULL）。mysql_init() 碰到NULL 参数，因此初始化并分配一个新的连接处理程式。只要将conn 传递给需要非NULL 连接处理程式的MySQLCAPI 函数，系统就会崩溃。这些代码段的修改就是确保conn 有一个可知的值。例如，能够将他初始化到已分配的MYSQL 结构地址中去：



然而，推荐的（较容易的！）解决方案仅仅是将NULL 显式地传递给mysql_ init( )，让该函数分配MYSQL 结构，并将返回值赋值给conn：



无论如何不要忘记检验mysql_init() 的返回值，以确保他不是NULL。

2. 错误2——有效结果集检验的失败

请记住检查希望得到的结果集的调用状态。下面的代码没有做到这一点：



不幸地是，假如mysql_store_result() 失败，res_set 为NULL，while 循环也不执行了，应测试返回结果集函数的返回值，以确保实际上在进行工作。

3. 错误3—— NULL 列值引起的失败

不要忘记检查mysql_fetch_row() 返回的数组MYSQL_ROW 中列值是否为NULL 指针。假如row[i] 为NULL，则在一些机器上，下面的代码就会引起崩溃：



该错误危害最大的部分是，有些printf() 的版本很宽容地对NULL指针输出了“( null )”，这就使错误很容易逃脱而没有把错误定位。假如把程式给了朋友，而他只有不太宽容printf( )版本，程式就会崩溃，您的朋友会认为您是个无用的程式员。循环应该写成下面这样：



无需检查列值是否为NULL 的惟一一次是当已从列信息结构确定IS _ NOT _ NULL( )为真时。

4. 错误4——传递无意义的结果缓冲区

需要您提供缓冲区的客户机库函数通常要使这些缓冲区真正存在，下面的代码违反了这个规则：



问题是什么呢？to_str 必须指向一个存在的缓冲区，而在这个样例中没有，因此，他指向了随意的位置。不要向mysql_escape_string 传递无意义的指针作为to_str 参数，否则他会恣意践踏内存。