今天在老王的技术手册看到一个问题:
<?php
if ($a = 100 && $b = 200) {
var_dump($a, $b);
}
输出是什么?
这个问题, 咋一看或许觉得简单, 但其实仔细推敲并不简单.
左手代码右手诗
今天在老王的技术手册看到一个问题:
<?php
if ($a = 100 && $b = 200) {
var_dump($a, $b);
}
输出是什么?
这个问题, 咋一看或许觉得简单, 但其实仔细推敲并不简单.
今天同事反馈一个问题, PHP5.2.x在使用反射做函数包装的时候, 得到"Invocation failed"的异常, 而使用call_user_func代替则不会,
原逻辑太复杂, 经过精简以后可重现异常的代码如下(使用ReflectionFunction为例, ReflectionMethod类似):
function who(&$name) {
echo $name;
}
$name = "laruence";
$method = new ReflectionFunction("who");
$method->invokeArgs(array($name));
//异常:
Uncaught exception 'ReflectionException' with message
'Invocation of function who() failed'
with 8 Comments
黑夜路人前段时间, 本着分享/总结的精神, 计划要总结下PHP常用的调试技术, 就一些问题找到了我..
如今第一版的PHP调试技术手册已经发布.
冠以我名, 我甚感惶恐, 只能一并赞下小黑的nice了~
下载地址: http://heiyeluren-doc.googlecode.com/files/PHP-Debug-Manual-public.pdf
PHP为了避免数字索引和数字字符串索引(注1)的混乱, 引入了zend_symtable_*系列函数, 并应用于数组中.
这样一来, 数字字符串索引也就会被当作数字索引, 然而总是有一些情况, 是PHP的维护者没有想到的...
比如, 类型转换时刻.
现在普遍的Nginx + PHP cgi的做法是在配置文件中, 通过正则匹配(Nginx(PHP/fastcgi)的PATH_INFO问题)设置SCRIPT_FILENAME, 今天小顿发现了一个这种方式的安全漏洞.
比如, 有http://www.laruence.com/fake.jpg, 那么通过构造如下的URL, 就可以看到fake.jpg的二进制内容:
http://www.laruence.com/fake.jpg/foo.php
为什么会这样呢?
在PHP4以前, PHP并不支持面向对象, 到PHP4的时候, PHP引入了一些OOP的关键字, 请注意我用的"关键字", 因为在PHP4中的对象, 不过就是一个数组(属性)加上一个函数数组(方法), 没有访问权限控制, 没有析构函数(当然可以模拟), 等等.
到PHP5以后, 随着Zend Engine 2的发布:
1. 访问权限控制 2. 接口的引入 3. 魔术方法(PHP4中可以通过overload来有限模拟) 4. 接口的应用 5. 内置接口 等等.
PHP5终于可以算是较完美的支持面向对象了.
而这些看似复杂的实现, 在根本上, 还是没有脱离属性数组+方法数组的基本, 接下来我就为大家揭开隐藏在源代码中的秘密.
最近公司组织了个PHP安全编程的培训, 其中涉及到一部分关于Mysql的"SET NAMES"和mysql_set_charset (mysqli_set_charset)的内容:
说到, 尽量使用mysqli_set_charset而不是"SET NAMES", 当然, 这个内容在PHP手册中也有叙及, 但是却没有解释为什么.
最近有好几个朋友问我这个问题, 到底为什么?
问的人多了, 我也就觉得可以写篇blog, 专门介绍下这部分的内容了.
因为东方时尚做了一些调整, 原来的脚本不能用了.
马上有人要报名了, 所以挑个时间升级了下.
目前是2.0, 可以无人值守.
升级了选择时段功能, 更加方便.
评论: 从最早听说Facebook搞一个神奇的项目开始, 我就在猜测它会怎么做? 想APC一样编译成Opcode? 或者是象phc从Opcode再次加工. 但, 今天看到的介绍, 让我还是有点出乎意料...哪就是- HipHop提供编译器, 让你可以"用PHP的语法写C++代码".
以下为转载原文:Facebook神秘的PHP项目HipHop for PHP终于揭开面纱。这个项目由一个PHP到C++的转换程序,一个重新实现的PHP运行库,和许多常用PHP扩展的重写版本构成,目的是旨在加速和优化 PHP。
一般来说,如果库的头文件不在 /usr/include 目录中,那么在编译的时候需要用 -I 参数指定其路径。由于同一个库在不同系统上可能位于不同的目录下,用户安装库的时候也可以将库安装在不同的目录下,所以即使使用同一个库,由于库的路径的不同,造成了用 -I 参数指定的头文件的路径也可能不同,其结果就是造成了编译命令界面的不统一。如果使用 -L 参数,也会造成连接界面的不统一。编译和连接界面不统一会为库的使用带来麻烦。
为了解决编译和连接界面不统一的问题,人们找到了一些解决办法。其基本思想就是:事先把库的位置信息等保存起来,需要的时候再通过特定的工具将其中有用的 信息提取出来供编译和连接使用。这样,就可以做到编译和连接界面的一致性。其中,目前最为常用的库信息提取工具就是下面介绍的 pkg-config...
Can't find what you're looking for? Try refining your search: