标签 Build 下的文章

C++咬文嚼字-'Hijack const'

晚上无意翻看Bjarne Stroustrup的'The C++ Programming Language Special Edition'(英文版)第94页,章节5.4 Constants一节,看到这么一句原文'C++ offers the concept of a user-defined constant, a const, to express the notion that a value doesn't change directly.'字眼就在directly上,既然不能directly change,那我试试indirectly change。

问题就发现于这个indirectly change,代码如下:

#include <iostream>

int main() {
 const int a = 2007;   // 这是一个常量,我们'不能directly change'^_^
 int *p = const_cast<int*>(&a);   //我们换一种方法hijack
 *p = 2008;    //篡改

 std::cout << "a = " << a << std::endl;  //期待输出2008
 std::cout << "*p = " << *p << std::endl;
 std::cout << "&a = " << &a << std::endl;
 std::cout << "p = " << p << std::endl;
 
 return 0;
}

我首先在Windows上使用Mingw的g++编译,输出结果让我大惊失色:
a = 2007
*p = 2008
&a = 0x23ff74
p = 0x23ff74

原以为a应该被hijack了,结果a仍然原封未动;关键是后两行打印的a的地址和p的指向都是一个地方,难道C++对常量的保护如此之好,如此智能。不行,换一个平台试试,我又把源码搬到了Solaris上同样是g++编译器,输出结果一致。

百思不得其解后继续'咬文嚼字'的往下看该小节。突然发现这么一句话:'If the compiler knows every use of the const, it need not allocate space to hold it.'…'The common simple and common case is the one in which the value of the constant is known at compile time and no storage needs to be allocated.',左思又想,这么一来在某些时候a被当作类似宏的方式处理的,就如:std::cout << "a = " << a << std::endl;这里cout输出一个常量表达式,编译器估计直接将a替换成2007了,实际上就相当于std::cout << "a = " << 2007 << std::endl;而后的int *p = const_cast<int*>(&a);操作,这时就需要为a分配地址了。有人说a的输出操作是在分配地址之后,那为什么还输出2007呢,我们从编译器的角度看看,编译器在解析到const int a = 2007的时候发现这是一个常量,便将之首先记录到常量符号表中,而后在解析const_cast<int*>(&a)时为a在栈上分配内存,但是在走到输出a那块时首先引用到的还是常量符号表,而输出&a时,由于是取地址操作,所以就把前面分配的栈地址赋到这里了。

我们继续再看一个例子:

#include <iostream>

int main() {
 int i = 2006;
 const int a = i + 1;   
 int *p = const_cast<int*>(&a);   
 *p = 2008;    //篡改

 std::cout << "a = " << a << std::endl;  //期待输出2008
 std::cout << "*p = " << *p << std::endl;
 std::cout << "&a = " << &a << std::endl;
 std::cout << "p = " << p << std::endl;
 
 return 0;
}

在这个例子中const int a = i + 1;用一个非常量表达式给常量a赋初值,按照Bjarne Stroustrup的说法,是需要给a分配内存了。这样我想编译器也许不会在常量符号表中给a留位置,在下面的a的打印输出时,a真的被hijack了。

输出结果:
a = 2008
*p = 2008
&a = 0x23ff70
p = 0x23ff70

再看一个例子:
#include <iostream>

int main() {
 const int i = 2006;
 const int a = i + 1;   
 int *p = const_cast<int*>(&a);   
 *p = 2008;    //篡改

 std::cout << "a = " << a << std::endl;  //期待输出2008
 std::cout << "*p = " << *p << std::endl;
 std::cout << "&a = " << &a << std::endl;
 std::cout << "p = " << p << std::endl;
 
 return 0;
}

编译器在解析到const int i = 2006时首先将i作为常量保存到常量符号表中,在const int a = i + 1时实际上相当于const int a = 2006 + 1,编译器作优化,编译器直接得到a = 2007而且是一个常量,也被保存到常量表中,下面的流程就和第一个例子一样了。

编译Ethereal On Windows

最近在研究项目下一期中新增的信令跟踪功能,在这个开源盛行的时代,开源工具当然是首选。我们发现了Ethereal,一款强大的网络分析工具包。我们不仅仅要使用Ethereal,而是在Ethereal上做二次开发,增加一个新dissector或者一个plugin,用来分析我们自己的应用层协议。

之所以选择Ethereal还有一个很重要的原因就是它已经支持300多个协议包了,这说明Ethereal的框架已经很成熟了,在其上面做二次开发具备可行性。我们最终要形成的成果物可能要运行在Solaris上,但是家里的服务器环境都是没有显示终端的,也看不到运行画面,所以我决定现在Windows上作开发,然后移植到Solaris上。Ethereal底层的图形接口采用的是GTK,GTK是一种可在跨平台的图形界面开发包,它屏蔽了不同OS的底层细节,便于我们的程序在各个OS平台上移植。由于GTK的使用,我才觉得我的开发方案是正确的:)。另外开发一个新的dissector涉及到的代码都应该是可移植的,所需的接口Ethereal都已经提供了,调用即可。所以我在想在Windows上开发成功后,拿到Solaris下重新编译后是应该能正确运行的,有些过于理想了^_^。

目前第一步工作就是先在Windows上编译Ethereal包,通过浏览Ethereal的Developer’s Guide和网上的一些资料得知,编译Ethereal并非易事呀,因为Ethereal依赖很多开源包以及一些其他工具(如Cygwin等)。虽然Ethereal提供的自动化构建脚本会自动下载依赖包,但是大多时候都会下载失败,我在公司的网络和家里的网络都尝试过,无一成功,无奈之中只好手工下载。依赖的开源工具包在Readme.win32中有列出。

(一)首先我们需要一个编译器,一般在Windows上编译Ethereal用的都是VC6.0的编译器,切记在装完VC6.0后运行一下vcvars32.bat,设置一下环境变量,一般VC的安装向导程序在最后一步都会提示你是否设置环境变量的,你同意即可。

(二)其次,编译Ethereal需要Cygwin这个工具,Cygwin呢,我在机器上早已经安装过了,我一直用它在Windows下写一些Unix下的小测试程序的。不过我当时安装的时候没有把所有的包都选择上,导致我还得重新运行Cygwin的Setup.exe程序。那么如何检查你的Cygwin中缺少哪些软件包呢,可以按照如下步骤来检查:
1. 将cygwin的bin目录作为环境变量加入到系统环境变量path中;
2. 在Windows命令提示符窗口下进入到Ethereal的源码包目录下,找到config.nmake文件,修改ETHEREAL_LIBS=C:\ethereal-win32-libs
   CYGWIN_PATH=c:\cygwin\bin;
3. 在Windows命令提示符窗口下运行:nmake -f Makefile.nmake verify_tools
如果有工具包没有装全,我们会从该命令的执行结果中看到的,比如我在运行该命令之后的输出结果为:
Microsoft (R) Program Maintenance Utility   Version 6.00.8168.0
Copyright (C) Microsoft Corp 1988-1998. All rights reserved.

Checking for required applications:
        cl: /cygdrive/d/Program Files/Microsoft Visual Studio/VC98/bin/cl
        link: /cygdrive/d/Program Files/Microsoft Visual Studio/VC98/bin/link
        nmake: /cygdrive/d/Program Files/Microsoft Visual Studio/VC98/bin/nmake

        bash: /usr/bin/bash
        bison: /usr/bin/bison

ERROR: Can’t find flex. This is probably an optional cygwin package not yet inst
alled. Try to install it using cygwin’s setup.exe!

NMAKE : fatal error U1077: ‘bash’ : return code ’0×1′
Stop.

可以看出flex这个工具包没有安装,还好找到一个很好的cygwin各种包的下载站点xmission,速度很快,缺少什么就上去下载,然后到cygwin的根目录’/'下,
bzip2 -d xx.tar.bz2
tar xvf xx.tar即可。
反复执行上面步骤直到运行verify_tools顺利通过为止。

下面是verify_tools运行通过的输出结果:
D:\Ethereal\ethereal-0.99.0>nmake -f Makefile.nmake verify_tools

Microsoft (R) Program Maintenance Utility   Version 6.00.8168.0
Copyright (C) Microsoft Corp 1988-1998. All rights reserved.

Checking for required applications:
        cl: /cygdrive/d/Program Files/Microsoft Visual Studio/VC98/bin/cl
        link: /cygdrive/d/Program Files/Microsoft Visual Studio/VC98/bin/link
        nmake: /cygdrive/d/Program Files/Microsoft Visual Studio/VC98/bin/nmake

        bash: /usr/bin/bash
        bison: /usr/bin/bison
        flex: /usr/bin/flex
        env: /usr/bin/env
        grep: /usr/bin/grep
        /usr/bin/find: /usr/bin/find
        perl: /usr/bin/perl
        env: /usr/bin/env
        python: /usr/bin/python
        sed: /usr/bin/sed
        unzip: /usr/bin/unzip
        wget: /usr/bin/wget

这里有一个小插曲,verify_tools命令使用的应该是cygwin中的bash shell,但是我起初运行verify_tools时始终提示我’which’包找不到,我检查了cygwin,明明’which’包已经安装了,我疑惑的查看了系统环境变量path,终于发现了蛛丝马迹,原来我以前安装过’UnxUtils‘软件包,运行verify_tools时用的是该包里的bash shell。把UnxUtil从path中删除,问题解决。

(三)我们要找全编译Ethereal所依赖的包,Readme.win32中也列出了依赖包的列表,以及这些包解压后应该释放到的位置:
必选的:
Package                                Location
    ——-                               —————-
    glib-2.4.7.zip                        C:\ethereal-win32-libs\glib
    glib-dev-2.4.7.zip                    C:\ethereal-win32-libs\glib
    gtk+-1.3.0-20030717.zip               C:\ethereal-win32-libs\gtk+
    gtk+-dev-1.3.0-20030115.zip           C:\ethereal-win32-libs\gtk+
    libiconv-1.9.1.bin.woe32.zip          C:\ethereal-win32-libs\libiconv-1.9.1.bin.woe32
    gettext-runtime-0.13.1.zip            C:\ethereal-win32-libs\gettext-runtime-0.13.1
    net-snmp-5.2.1.2.zip                  C:\ethereal-win32-libs
    wpdpack_3_0.zip                       C:\ethereal-win32-libs

可选的:
Package                                Location
    ——-                               —————-
    adns-1.0-win32-04.zip                 C:\ethereal-win32-libs
    pcre-4.4.zip                          C:\ethereal-win32-libs
    zlib123-dll.zip                       C:\ethereal-win32-libs\zlib123-dll

尽量按照Package的版本下载,否则除了问题很难搞定,这里面除了net-snmp我没有找到5.2.1.2版本,我用了5.2.3替代之外,其余的都可以找到,这里有个站点http://mirror.sg.depaul.edu/pub/security/ethereal/win32/development/,几乎可以下载到上面所有的软件。net-snmp我下载的是源码包,需要先编译一下,记住编译Release版本即可。

(四)最后一步执行:nmake -f Makefile.nmake all
编译过程中的几个问题:
1. 编译过程中经常会中断,很多是因为’can’t open the file ‘uni
std.h”这个头文件,如果出现这样的问题,可以修改出错源文件的代码,将#include <unistd.h>修改为
#ifdef HAVE_UNISTD_H
#include<unistd.h>
#endif
即可。

2. 另外在编译过程中还发现需要lua5.1这个包。
3. 如果你下载的是gtk 1.x的包,你就是用gtk+这个目录,并且需要在config.nmake中注释掉GTK2_DIR=$(ETHEREAL_LIBS)\gtk2这项,我在编译中如果不注释掉该项,始终编译不过去。

编译过程很耗时,也许是我的本本CPU主频低的缘故,这可是考验耐性的活儿呀^_^。

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! Go语言第一课 Go语言精进之路1 Go语言精进之路2 Go语言编程指南
商务合作请联系bigwhite.cn AT aliyun.com

欢迎使用邮件订阅我的博客

输入邮箱订阅本站,只要有新文章发布,就会第一时间发送邮件通知你哦!

这里是 Tony Bai的个人Blog,欢迎访问、订阅和留言! 订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠 ,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:

如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:

以太币:

如果您喜欢通过微信浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:
本站Powered by Digital Ocean VPS。
选择Digital Ocean VPS主机,即可获得10美元现金充值,可 免费使用两个月哟! 著名主机提供商Linode 10$优惠码:linode10,在 这里注册即可免费获 得。阿里云推荐码: 1WFZ0V立享9折!


View Tony Bai's profile on LinkedIn
DigitalOcean Referral Badge

文章

评论

  • 正在加载...

分类

标签

归档



View My Stats