除了分配器函数核心部分外，还存在其它一些非常方便的ZendMM特定的函数，例如：

void *estrndup(void *ptr，int len);

　　该函数能够分配len+1个字节的内存并且从ptr处复制len个字节到最新分配的块。这个estrndup()函数的行为可以大致描述如下：

void *estrndup(void *ptr， int len)
{
　char *dst = emalloc(len + 1);
　memcpy(dst， ptr， len);
　dst[len] = 0;
　return dst;
}

　　在此，被隐式放置在缓冲区最后的NULL字节可以确保任何使用estrndup()实现字符串复制操作的函数都不需要担心会把结果缓冲区传递给一个例如printf()这样的希望以为NULL为结束符的函数。当使用estrndup()来复制非字符串数据时，最后一个字节实质上都浪费了，但其中的利明显大于弊。

void *safe_emalloc(size_t size， size_t count， size_t addtl);
void *safe_pemalloc(size_t size， size_t count，size_t addtl，char persistent);

　　这些函数分配的内存空间最终大小是((size*count)+addtl)。你可以会问："为什么还要提供额外函数呢？为什么不使用一个emalloc/pemalloc呢？"原因很简单：为了安全。尽管有时候可能性相当小，但是，正是这一"可能性相当小"的结果导致宿主平台的内存溢出。这可能会导致分配负数个数的字节空间，或更有甚者，会导致分配一个小于调用程序要求大小的字节空间。而safe_emalloc()能够避免这种类型的陷井-通过检查整数溢出并且在发生这样的溢出时显式地预以结束。

　　注意，并不是所有的内存分配例程都有一个相应的p*对等实现。例如，不存在pestrndup()，并且在PHP 5.1版本前也不存在safe_pemalloc()。

　　五、 引用计数

　　慎重的内存分配与释放对于PHP（它是一种多请求进程）的长期性能有极其重大的影响；但是，这还仅是问题的一半。为了使一个每秒处理上千次点击的服务器高效地运行，每一次请求都需要使用尽可能少的内存并且要尽可能减少不必要的数据复制操作。请考虑下列PHP代码片断：

＜?php
$a = 'Hello World';
$b = $a;
unset($a);
?＞

　　在第一次调用之后，只有一个变量被创建，并且一个12字节的内存块指派给它以便存储字符串"Hello World"，还包括一个结尾处的NULL字符。现在，让我们来观察后面的两行：$b被置为与变量$a相同的值，然后变量$a被释放。

　　如果PHP因每次变量赋值都要复制变量内容的话，那么，对于上例中要复制的字符串还需要复制额外的12个字节，并且在数据复制期间还要进行另外的处理器加载。这一行为乍看起来有点荒谬，因为当第三行代码出现时，原始变量被释放，从而使得整个数据复制显得完全不必要。其实，我们不妨再远一层考虑，让我们设想当一个10MB大小的文件的内容被装载到两个变量中时会发生什么。这将会占用20MB的空间，此时，10已经足够了。引擎会把那么多的时间和内存浪费在这样一种无用的努力上吗？

　　你应该知道，PHP的设计者早已深谙此理。

　　记住，在引擎中，变量名和它们的值实际上是两个不同的概念。值本身是一个无名的zval*存储体（在本例中，是一个字符串值），它被通过zend_hash_add()赋给变量$a。如果两个变量名都指向同一个值，会发生什么呢？

{
　zval *helloval;
　MAKE_STD_ZVAL(helloval);
　ZVAL_STRING(helloval， "Hello World"， 1);
　zend_hash_add(EG(active_symbol_table)， "a"， sizeof("a")，&helloval， sizeof(zval*)， NULL);
　zend_hash_add(EG(active_symbol_table)， "b"， sizeof("b")，&helloval， sizeof(zval*)， NULL);
}

　　此时，你可以实际地观察$a或$b，并且会看到它们都包含字符串"Hello World"。遗憾的是，接下来，你继续执行第三行代码"unset($a);"。此时，unset()并不知道$a变量指向的数据还被另一个变量所使用，因此它只是盲目地释放掉该内存。任何随后的对变量$b的存取都将被分析为已经释放的内存空间并因此导致引擎崩溃。