ullib常见疑问以及解答.doc

ULLIB常见疑问以及解答 以下针对ullib使用中的一些常见问题做出解答，希望对大家的日常工作有所帮助。1 ul_log调用过程中，日志过长是否会截断？截断长度是多少?如何解决？A：目前日志长度定义为640，过长会截断。#define BUFSIZE_INDATA 640目前建议过长的log采取多次调用的方式来规避这一问题；com组正在尝试升级ullib解决这一问题，预计在下一版本中会有所体现。2 用新版本的ullib过程中，ul_log调用时，打印log的语句报warning如何处理？为什么在老的版本中不会报这样的警告或错误？A：由于在ullib_3-1-4-0_PD_BL以前的版本中，对省略参数的格式是不加以判断的，这样导致程序中留下一些潜在的bug和危险，但不会报错。ullib_3-1-4-0_PD_BL以后，ullib增加了对对日志省略参格式的判断，在初期会导致一些原来潜在的错误集中暴露出来，建议针对这些warning仔细检查，认真修改即可。另外，有些makefile中，强制指定了warning当作错误处理，就会报很多格式上的错误信息，同样需要认真修改格式错误。3 在64为系统使用ul_log设置UL_LOGTTY时，为什么会产生异常？A：这是一个ul_log中的64位bug，具体表现在：1）当设置UL_LOGTTY时，屏幕输出有时为(NULL)；2）设置UL_LOGTTY时，有可能出core。这是因为：ul_log中处理省略参数时，调用va_start后，未调用va_end复位，导致内部指针偏移，产生不可预知的错误，表现为返回null，乱码，或core。目前的解决方案为：尽量不要使用UL_LOGTTY选项，如果需要使用，请先与com组联系，确定当前版本是否修复此bug，之后再使用。4 ul_tolowerstr_singlebuf是否支持双字节字符？A：这个函数不区分单字节字符或双字节字符，会将取值在AZ的字节转换为相应的小写的字母。GBK的有些汉字，低字节可以取值为0X400X7E，很不幸，大写英文字母就在这个范围内（0x410x5A），所有大写会变小写，汉字被破坏。所以，这个函数只有在处理纯iso-8859字符才是安全的。因此，当处理中文时，推荐使用ul_trans2lower函数，这个函数是对中文安全的。5 lib2和老的lib共存的情况下，在使用lib2的过程中，如果程序使用的其他静态库是采用老的lib编译出来的，会不会产生问题？A：不会产生问题。例如：program需要使用lib2，而program同时需要静态库myapp.a的支持，而myapp.a文件依赖旧的函数库，这种情况下不会产生冲突。因为：l 形成myapp.a，仅仅是编译（compire），没有做任何链接（link）l 真正的链接是在应用程序编译时发生的，应用程序指定使用哪个ullib库，就链接哪个ullib库，和myapp.a依赖哪个库编译无关。故而：l myapp.a不需要在lib2环境下重新编译l 允许新旧库并存总结如下：l 现在，旧ullib和lib2的实现完全相同，仅仅是编译路径不同，所以现在新旧函数库并存完全没有问题l 如果今后升级，lib2做了修改，即同一个函数在旧ullib和lib2中有不同的表现。应用程序到底是实现了哪个功能，归根结底要看应用程序链接时指向旧ullib或lib2，而和中间引用（如自己写的.a文件）无关。6 uln_http_crawlpage()这个网页抓取函数中可以设定user-agent的设定么？A:不允许。因为user-agent的设定需要依靠uln_request_t *ereq参数，而函数uln_http_crawlpage无法设置这个参数，原因如下：int uln_http_crawlpage(const char* url,const char* ip,int maxlen, uln_response_t * pres,int ntimeout,int flag) return uln_http_crawlpage_ex(url, ip, maxlen, pres, ntimeout, flag, NULL); 因此，请选择uln_http_crawlpage_ex函数代替它。举例如下： uln_request_t *ereq = uln_http_initreq(url,ip);if (ereq = NULL) return -1;if (uln_vec_setvalue(ereq-m_req_head,user-agent,Your user-agent) node.code = -1; node.other = 0; db_op1(dict,&node,ADD); node.code = v1; node.other = v2; db_op1(dict,&node,MOD);10编译dict相关模块的时候，报undefined reference to MD5错误，如何处理？A：由于在lib2里面添加了creat_sign_md64 creat_sign_mds64 两个函数，作用是采用md5签名折叠形成64位key，这两个函数需要调用libcrypto.a中的函数，所以在连接的时候，容易报类似下面的错误：./././lib2/dict/lib/libuldict.a(ul_sign.o): In function creat_sign_md64(char *, int, unsigned int *, unsigned int *):/home/wangjian/libsrc/dict/ul_sign.cpp:367: undefined reference to MD5./././lib2/dict/lib/libuldict.a(ul_sign.o): In function creat_sign_mds64(char *, int, unsigned int *, unsigned int *):/home/wangjian/libsrc/dict/ul_sign.cpp:377: undefined reference to MD5解决办法为：在makefile中连接的部分，添加-lcrypto库支持，即可编译通过。11使用ul_url时，当url长度超过256或者path长度超过203，如何处理？A：在当前使用的url函数中，由于宏定义的限制，url解析有以下长度限制：site字段最大长度为48port字段最大长度为7path字段最大长度为203目前遇到一些特殊的url，有可能打破这种字段限制，导致无法正常进行url解析操作。目前com组针对这种情况，在ullib_3-1-5-1_PD_BL版本以后，已经增加了对超长的url的支持。由于历史原因，直接修改原有的宏定义存在一定风险，因此采用增加_ex版本的新接口来解决此问题。例如ul_parse_url函数，支持超长的url版本为ul_parse_url_ex。具体使用方法可参见/ullib/doxygen-doc/ul_url_8h.html中的接口文档。12关于使用ul_gethostbyname_r时，在异常情况下会出core，并且64位/32位返回值不一致的问题，如何处理？A：这一函数出现的问题比较多，主要体现在以下几个方面：l 当传入一个错误的ip地址时，返回值为成功，而后续操（例如copy h_addr结构时）就会出core。l 当传入错误的主机名时，32位和64位的返回值会有所不同，无从判断。这种异常主要是由于不同版本的glibc对gethostbyname_r的实现有所不同所导致。解决这一方法，有以下方法：l 升级ullib到ullib_3-1-5-1_PD_BL以上，在ullib_3-1-5-1_PD_BL版本中，ullib已经修复了此问题。l 如果依然使用老的ullib，需要修改原代码做足够的守护，具体方法为：增加对h_err!=0的判断和result=NULL的判断,两者只要有一者成立，则可认为ul_gethostby_name_r返回失败。13Config调用中，目前value的长度最大可为多少，如果不够怎么处理？ A：在老版本中（ullib_3-1-0-0_PD_BL以前），ul_conf行的最大长度不可超过256，并且value的长度也不能超过256，在ullib_3-1-0-0_PD_BL版本以后，扩大了长度限制，目前行的最大长度可支持2048,value字段的最大长度为1024。如果依然不够，考虑到处理成本，以及应用的特殊性，建议采用其他方式实现。毕竟从设计初衷来看，作为读取config的工具，这个长度应该够用了。14在编译过程中，出现异常undefined reference error如何处理？A：这个错误在调用lib的时候，会经常遇到，因此做如下讨论：该错误的本质是编译时声明的实体（变量、函数等）在连接时找不到对应的定义。经过前后摸索并查阅一些资料，把可能的原因总结如下，供各位参考：1. 没有指定对应的库（.o/.a/.so）使用了库中定义的实体，但没有指定库（-lXXX）或者没有指定库路径（-LYYY），会导致该错误2. 连接库参数的顺序不对（缺省情况下）每个库在连接时按照命令行参数的顺序被搜索并且只搜索一次，后面的库如果用到了前面的库中定义的实体，可能导致该错误所以最好按照库的依赖关系来按序写参数，被依赖的库放在后面3. gcc/ld版本不匹配gcc/ld的各版本间兼容性并不是很好（最明显表现于3.3和3.4之间），比如低版本编译的库用高版本来进行连接，也可能会导致该错误，目前ullib这种情况出现的比较多，解决问题的办法是，保持库的编译环境和当前程序编译环境的兼容性。4.