last updated: 4/15/07

** KNOWN REGRESSIONS **
linux:
1123: base64 encode/decode (only amd64?)


Other Known (acceptable) Failures:
----------------------------------

linux:

3091
1901
1886
1142
1052 (compiled)

mingw (in addition to above):

1158
1152 **
1135 **
1125
1118
0892

(** means it fails for unknown reasons)

--------

In a perfect world, none of these tests would fail.  However, there
are currently several failures that we're tolerating, in the hopes
that the situation will be resolved at some time in the future.  So
this list doesn't mean that these tests are meant to fail, just that
you should probably expect them to.


1886 and 1901 because of recursive var_dump incompatibility

there is an incompatibility between our var_dump and php's on
recursive data.

I've filed two bugs about different problems in php's var_dump(),
which some yutz collapsed into one bug -- #29390.


1052 fails compiled, but not interpreted.  

We compile in the "project relative pathname" instead of the absolute
pathname, so that include() is easier.


1142 fails because php's strrchr seems not to be binary safe


3091 behaves differently in older versions of php.  In older versions
of PHP, (int)$fp is 1, in newer versions it's 0, it seems.


--------

mingw:

1158 fails because of our gettimeofday implementation. seems like we're 
     loosing resolution on microseconds, so the uniqid function (which
     uses the time to generate the id) is coming up with the same value
     twice, because the microseconds aren't changing quick enough.

1152 i can't figure out why it says it fails. diff thinks it's binary
     output, so there must be a hidden high character because the output
     looks visually identical

1135 php: "1  1.1000e+0" us: "1 1.1000e+00", which is right?

1125 float accuracy

1118 we don't support ftruncate on mingw. should we?

0892 no posix on mingw

