Please try using a plain PHP fetched either from our svn or from a release 
download.

I have been able to reproduce the bug under Ubuntu Linux (2.6.32) and a clean 5.3.8 release download:  PHP 5.3.8 (cli) (built: Sep 17 2011 14:59:12)

ah, sorry, I misread the *0 part. Please see the documentation (salt length, 
return value on failure).

I'm sorry to be persistent, but I don't think that this is a problem with the salt length.

To demonstrate, I have run crypt on several platforms with several versions of PHP.  I ran crypt with the same string, but a different salt that varied by just one character:

1st case:  crypt("veronica", "aQ");
2nd case:  crypt("veronica", "_Q");

The first case produces the same hashed string in all versions and platforms.
The second cases produces a proper hashed string with the 5.1 and 5.2 variants, but not so with most of the 5.3 variants.

Results for 1st case [crypt("veronica", "aQ")]:
PHP 5.1.6 (cli) / RHEL Linux 2.6.18:  aQW/7xmAl9Wk.
PHP 5.2.17 (cli) / RHEL Linux 2.6.18:  aQW/7xmAl9Wk.
PHP 5.3.2-1ubuntu4.9 with Suhosin-Patch (cli) / Linux :  aQW/7xmAl9Wk.
PHP 5.3.0 (cli) / RHEL Linux 2.6.18: aQW/7xmAl9Wk.
PHP 5.3.4 (cli) / RHEL Linux 2.6.18: aQW/7xmAl9Wk.
PHP 5.3.6 (cli) / RHEL Linux 2.6.18: aQW/7xmAl9Wk.
PHP 5.3.8 (cli) / Ubuntu Linux (2.6.32):  aQW/7xmAl9Wk.
PHP 5.3.8 with Suhosin-Patch (cli) / FreeBSD 7.2 :  aQW/7xmAl9Wk.


Results for the 2nd case [crypt("veronica", "_Q")]:

PHP 5.1.6 (cli) / RHEL Linux 2.6.18:  _Q9SLgD4qEEgM
PHP 5.2.17 (cli) / RHEL Linux 2.6.18:  _Q9SLgD4qEEgM
PHP 5.3.2-1ubuntu4.9 with Suhosin-Patch (cli) / Linux :  _Q9SLgD4qEEgM
PHP 5.3.0 (cli) / RHEL Linux 2.6.18: _Q$$$$$$$qK1ZM2vrJkU
PHP 5.3.4 (cli) / RHEL Linux 2.6.18: *0
PHP 5.3.6 (cli) / RHEL Linux 2.6.18: *0
PHP 5.3.7 with Suhosin-Patch (cli) / FreeBSD 7.2 :   *0
PHP 5.3.8 (cli) / Ubuntu Linux (2.6.32):  *0
PHP 5.3.8 with Suhosin-Patch (cli) / FreeBSD 7.2 :   *0

it is not about the length, and not about having underscore in the salt, as then 
both '_a' and 'a_' should produce *0, but it isn't:
crypt("veronica", "a_") returns  'a_CzfMnN285eI'
I also tried calling crypt with longer salt:
crypt("veronica", "aaaaaaaaaaaaaaaa_");
produces "aaN/k77JE/bN6" on both 5.2.17 and 5.3.8
but crypt("veronica", "_aaaaaaaaaaaaaaaa"); differs:
"_aaaaaaaadgbQ2NJa866" for 5.3.8
"_aeK.1tgvo.I." for 5.3.8

so it seems that _ only cause problems, if it is in the first position of the 
salt.

ps: I also tried replacing the starting undescore with other "special" 
characters(^,!,#), they produced the same result on both 5.2.18 and 5.3.8, so it 
seems that it happens only with underscore.

could someone have another look?

@tyrael: If the salt starts with an underscore it's an Extended DES hash, not a standard DES hash.

The actual problem is that this should give (*0) everywhere as far as I can see: PHP fills the salt up to max salt length with '$' and this isn't a valid Extented DES count or salt.

The relevant code is here: http://lxr.php.net/xref/PHP_5_3/ext/standard/crypt_freesec.c#638

It seems to me that everything works as expected for the supported
PHP versions[1].

[1] <https://www.php.net/supported-versions.php>