Re: [PHP-DEV] [PATCH] OCI8 link failure (Tru64/AIX) (#22324)
Jani Taskinen [EMAIL PROTECTED] wrote: I still don't think we should be linking with libocijdbc8 in any case. Can you ask some Oracle support why their libs differ with same version but in different OSes?? I can try to do so [1], although I don't see what that will buy us. From Oracle9i Administrator's Reference http://download-east.oracle.com/docs/html/A97297_01/ch4_comp.htm#i26133, chapter 4, Using Oracle Precompilers and the Oracle Call Interface: | Custom Make Files | | Oracle Corporation recommends that you use the provided demo_product.mk | make files to create user programs as described in the specific product | sections of this chapter. | [...] | If you choose to use a make utility such as nmake or GNU make, be aware | of how macro and suffix processing differs from the make utility | provided with the platform. Oracle make files are tested and are | supported with the make utility for your platform. The demo_product.mk is in reality called demo_rdbms.mk - and of course it's virtually undocumented. | Oracle library names and the contents of Oracle libraries are subject to | change between releases. Always use the demo_product.mk make file that | ships with the current release as a guide to determine the required | libraries. Then they go on to explain their symfind utility, which is a shell script around find, grep and nm - with platform-specific output [2]. | Correcting Undefined Symbols (Solaris Only) | | Oracle provides the symfind utility to assist you in locating a library | or object file where a symbol is defined. When linking a program, | undefined symbols are a common error that produce an error message | similar to the following: IMHO this is totally unacceptable. If they can't provide a well-defined set of interface libraries, they should at least offer some kind of oci-config or a few text files with -lsomelib -lanotherlib lines. But no matter how hard we wish they had some such thing, they don't have it at the moment - and even if they would suddenly start to clean up that whole mess, it would probably take a long time until their patches would be installed everywhere. I still think that the best solution would be to check if linking with -lcntsh alone is enough to get OCILobIsTemporary, and if not, check if it works with -locijdbc8. Regards... Michael [1]: My question in the Oracle Technology Network forum has not been answered for two weeks now, ditto in comp.databases.oracle.misc. [2]: Symfind (or nm) finds the OCILobIsTemporary definition (T) not only in libocijdbc8.so, but also in libclntsh.so and a few other libs: OCILobIsTemporary| | U | 0008 ^^^ ./lib/libsql8.a OCILobIsTemporary| 0004396969863776 | T | 0008 ^^^ ./lib/libnjni8.so OCILobIsTemporary| 5408 | T | 0008 ^^^ ./lib/libclient8.a OCILobIsTemporary| 5408 | T | 0008 OCILobIsTemporary| | U | 0008 ^^^ ./lib/libclntst8.a OCILobIsTemporary| 0004396969227952 | T | 0008 ^^^ ./lib/libocijdbc8.so OCILobIsTemporary| 0004396962545744 | T | 0008 ^^^ ./lib/libocijdbc8_g.so OCILobIsTemporary| | U | 0008 ^^^ ./lib/libsqlplus.a OCILobIsTemporary| | U | 0008 ^^^ ./lib/libordim8.a OCILobIsTemporary| 0004396966909952 | T | 0008 ^^^ ./lib/libclntsh.so This is on the Compaq/HP test drive with Tru64 5.1 and Oracle 8.1.7. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] OCI8 link failure (Tru64/AIX) (#22324)
Hi, this is a repost of my article from Monday, 03 March. Perhaps it has gone unnoticed because of the discussion about OnUpdateInt()? If it was noticed, but the patch just sucks, please say so. My older patch for the link problems with OCI8 on Tru64 broke the build on AIX and maybe other systems, so Jani commented it out. Here comes a better patch. Instead of just linking to libocijdbc8/9 if it is available, it tries to find the OCILobIsTemporary function in the normal libclntsh first, and does nothing if it's there. Only if OCILobIsTemporary is not in libclntsh, another check is done to search it in libocijdbc8/9. I tested it on Linux with Oracle 8.1.6, Tru64 with 8.1.6, 8.1.7 and 9.0.1, and made sure that libocijdb8/9 is linked only when necessary. The patch is not yet tested on AIX, though. I'll ask the two people who reported bug #22324 after the patch has been applied (or should I ask them before the patch is applied, and send them the new configure and main/php_config.h.in built here?). Just before posting this, I became aware that at least here (Linux, Oracle 8.1.6), the line AC_DEFINE(HAVE_OCI8_SHARED_MODE,1,[ ]) results in a core dump at startup, if I use --with-oci8=shared. This is a separate problem (#22521), it also happens without my patch. Setting OCI_USE_EMALLOC to 1 in oci8.c doesn't change it. Regards... Michael Index: ext/oci8/config.m4 === RCS file: /repository/php4/ext/oci8/config.m4,v retrieving revision 1.37.2.3 diff -u -B -b -r1.37.2.3 config.m4 --- ext/oci8/config.m4 25 Feb 2003 04:37:08 - 1.37.2.3 +++ ext/oci8/config.m4 3 Mar 2003 20:45:03 - @@ -89,14 +89,20 @@ 8.1) PHP_ADD_LIBRARY(clntsh, 1, OCI8_SHARED_LIBADD) -dnl This breaks build on some systems (AIX at least). -dnl if test -f $OCI8_DIR/lib/libocijdbc8.so ; then -dnl PHP_ADD_LIBRARY(ocijdbc8, 1, OCI8_SHARED_LIBADD) -dnl fi - PHP_ADD_LIBPATH($OCI8_DIR/lib, OCI8_SHARED_LIBADD) + + php_save=$LDFLAGS + LDFLAGS=-L$OCI8_DIR/lib $LDFLAGS + AC_CHECK_LIB(clntsh, OCILobIsTemporary, [ ], [ +AC_CHECK_LIB(ocijdbc8, OCILobIsTemporary, [ + PHP_ADD_LIBRARY_WITH_PATH(ocijdbc8, $OCI8_DIR/lib, OCI8_SHARED_LIBADD) +], [ ]) + ]) + LDFLAGS=$php_save + AC_DEFINE(HAVE_OCI8_TEMP_LOB,1,[ ]) - AC_DEFINE(HAVE_OCI8_SHARED_MODE,1,[ ]) + + dnl AC_DEFINE(HAVE_OCI8_SHARED_MODE,1,[ ]) dnl dnl OCI_ATTR_STATEMENT is not available in all 8.1.x versions @@ -107,12 +113,17 @@ 9.0) PHP_ADD_LIBRARY(clntsh, 1, OCI8_SHARED_LIBADD) -dnl This breaks build on some systems (AIX at least) -dnl if test -f $OCI8_DIR/lib/libocijdbc8.so ; then -dnl PHP_ADD_LIBRARY(ocijdbc8, 1, OCI8_SHARED_LIBADD) -dnl fi - PHP_ADD_LIBPATH($OCI8_DIR/lib, OCI8_SHARED_LIBADD) + + php_save=$LDFLAGS + LDFLAGS=-L$OCI8_DIR/lib $LDFLAGS + AC_CHECK_LIB(clntsh, OCILobIsTemporary, [ ], [ +AC_CHECK_LIB(ocijdbc9, OCILobIsTemporary, [ + PHP_ADD_LIBRARY_WITH_PATH(ocijdbc9, $OCI8_DIR/lib, OCI8_SHARED_LIBADD) +], [ ]) + ]) + LDFLAGS=$php_save + AC_DEFINE(HAVE_OCI8_TEMP_LOB,1,[ ]) AC_DEFINE(HAVE_OCI8_ATTR_STATEMENT,1,[ ]) AC_DEFINE(HAVE_OCI8_SHARED_MODE,1,[ ]) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] news.php.net - mailing list gateway broken?
Hi, I'm using nntp://news.php.net to post to the php-dev mailing list - at least I hoped so. My (very few) articles show up nicely on http://news.php.net and on http://groups.google.com, but in the mailing list archives they end up with just an IP address as From: address (see e.g. http://marc.theaimsgroup.com/?l=php-devm=104712105011151w=2). I suspect that this sort of From: is dropped right on the floor by the mailing list software. So I subscribed to the real mailing list, and now send this article as a test. Regards... Michael -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: news.php.net - mailing list gateway broken?
I wrote: [...] in the mailing list archives they end up with just an IP address as From: address (see e.g. http://marc.theaimsgroup.com/?l=php-devm=104712105011151w=2). I suspect that this sort of From: is dropped right on the floor by the mailing list software. No, the article looks ok on the mailing list; only in the archive the From: gets replaced by the X-Posted-By:. Regards... Michael -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Patch for OCI8 link failure (Tru64/AIX) (#22324)
Hi, my older patch for the link problems with OCI8 on Tru64 broke the build on AIX and maybe other systems, so Jani commented it out. Here comes a better patch. Instead of just linking to libocijdbc8/9 if it is available, it tries to find the OCILobIsTemporary function in the normal libclntsh first, and does nothing if it's there. Only if OCILobIsTemporary is not in libclntsh, another check is done to search it in libocijdbc8/9. I tested it on Linux with Oracle 8.1.6, Tru64 with 8.1.6, 8.1.7 and 9.0.1, and made sure that libocijdb8/9 is linked only when necessary. The patch is not yet tested on AIX, though. I'll ask the two people who reported bug #22324 after the patch has been applied (or should I ask them before the patch is applied, and send them the new configure and main/php_config.h.in built here?). Just before posting this, I became aware that at least here (Linux, Oracle 8.1.6), the line AC_DEFINE(HAVE_OCI8_SHARED_MODE,1,[ ]) results in a core dump at startup, if I use --with-oci8=shared. This is a separate problem (#22521), it also happens without my patch. Setting OCI_USE_EMALLOC to 1 in oci8.c doesn't change it. Regards... Michael Index: ext/oci8/config.m4 === RCS file: /repository/php4/ext/oci8/config.m4,v retrieving revision 1.37.2.3 diff -u -B -b -r1.37.2.3 config.m4 --- ext/oci8/config.m4 25 Feb 2003 04:37:08 - 1.37.2.3 +++ ext/oci8/config.m4 3 Mar 2003 20:45:03 - @@ -89,14 +89,20 @@ 8.1) PHP_ADD_LIBRARY(clntsh, 1, OCI8_SHARED_LIBADD) -dnl This breaks build on some systems (AIX at least). -dnl if test -f $OCI8_DIR/lib/libocijdbc8.so ; then -dnl PHP_ADD_LIBRARY(ocijdbc8, 1, OCI8_SHARED_LIBADD) -dnl fi - PHP_ADD_LIBPATH($OCI8_DIR/lib, OCI8_SHARED_LIBADD) + + php_save=$LDFLAGS + LDFLAGS=-L$OCI8_DIR/lib $LDFLAGS + AC_CHECK_LIB(clntsh, OCILobIsTemporary, [ ], [ +AC_CHECK_LIB(ocijdbc8, OCILobIsTemporary, [ + PHP_ADD_LIBRARY_WITH_PATH(ocijdbc8, $OCI8_DIR/lib, OCI8_SHARED_LIBADD) +], [ ]) + ]) + LDFLAGS=$php_save + AC_DEFINE(HAVE_OCI8_TEMP_LOB,1,[ ]) - AC_DEFINE(HAVE_OCI8_SHARED_MODE,1,[ ]) + + dnl AC_DEFINE(HAVE_OCI8_SHARED_MODE,1,[ ]) dnl dnl OCI_ATTR_STATEMENT is not available in all 8.1.x versions @@ -107,12 +113,17 @@ 9.0) PHP_ADD_LIBRARY(clntsh, 1, OCI8_SHARED_LIBADD) -dnl This breaks build on some systems (AIX at least) -dnl if test -f $OCI8_DIR/lib/libocijdbc8.so ; then -dnl PHP_ADD_LIBRARY(ocijdbc8, 1, OCI8_SHARED_LIBADD) -dnl fi - PHP_ADD_LIBPATH($OCI8_DIR/lib, OCI8_SHARED_LIBADD) + + php_save=$LDFLAGS + LDFLAGS=-L$OCI8_DIR/lib $LDFLAGS + AC_CHECK_LIB(clntsh, OCILobIsTemporary, [ ], [ +AC_CHECK_LIB(ocijdbc9, OCILobIsTemporary, [ + PHP_ADD_LIBRARY_WITH_PATH(ocijdbc9, $OCI8_DIR/lib, OCI8_SHARED_LIBADD) +], [ ]) + ]) + LDFLAGS=$php_save + AC_DEFINE(HAVE_OCI8_TEMP_LOB,1,[ ]) AC_DEFINE(HAVE_OCI8_ATTR_STATEMENT,1,[ ]) AC_DEFINE(HAVE_OCI8_SHARED_MODE,1,[ ]) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP_CHECK_FUNC and shared extension (OCI8)
Hi, how do I use PHP_CHECK_FUNC to make it work even when the extension is shared? In ext/oci8/config.m4, if I use PHP_ADD_LIBPATH($OCI8_DIR/lib, OCI8_SHARED_LIBADD) PHP_CHECK_FUNC(OCILobIsTemporary, clntsh, ocijdbc8) it works when configured --with-oci8, but not with --with-oci8=shared. With --with-oci8=shared, the test case in configure does not give -L$OCI8_DIR/lib to gcc, so it cannot work. My previous approach: AC_SEARCH_LIBS(OCILobIsTemporary, ocijdbc8, [ PHP_ADD_LIBRARY(ocijdbc8, 1, OCI8_SHARED_LIBADD) ], [ ], -lclntsh) suffers from the same problem. Apparently, I'm something missing here. FWIW, I append a patch for current 4.3.2-dev, although I have not been able to test it on anything else then Linux with Oracle 8.1.6. The patch should not affect those systems that find OCILobIsTemporary with -lclntsh alone. --with-oci8=shared should be no problem there, although the configure messages checking for OCILobIsTemporary in -lclntsh... no checking for __OCILobIsTemporary in -lclntsh... no checking for OCILobIsTemporary in -locijdbc8... no checking for __OCILobIsTemporary in -locijdbc8... no are misleading. On Tru64 (where OCILobIsTemporary needs -locijdbc8), it should work --with-oci8, but still not --with-oci8=shared. In case somebody wants to test the patch, I put a bzip'ed configure (built with autoconf 2.13, automake 1.5, libtool 1.4.3) on http://elmicha.de/tools/configure.bz2. Prehistory: http://bugs.php.net/bug.php?id=18640 http://bugs.php.net/bug.php?id=22324 http://groups.google.com/groups?selm=setsixhu9.ln2%40elmicha.33322251-0001.dialin.t-online.de Regards... Michael --- ext/oci8/config.m4.orig Sat Mar 1 13:06:55 2003 +++ ext/oci8/config.m4 Sat Mar 1 13:15:37 2003 @@ -89,12 +89,14 @@ 8.1) PHP_ADD_LIBRARY(clntsh, 1, OCI8_SHARED_LIBADD) -dnl This breaks build on some systems (AIX at least). -dnl if test -f $OCI8_DIR/lib/libocijdbc8.so ; then -dnl PHP_ADD_LIBRARY(ocijdbc8, 1, OCI8_SHARED_LIBADD) -dnl fi - PHP_ADD_LIBPATH($OCI8_DIR/lib, OCI8_SHARED_LIBADD) + + dnl Does not work with --with-oci8=shared on those + dnl systems (e.g. Tru64) where OCILobIsTemporary is found in + dnl libocijdbc8.so. + dnl + PHP_CHECK_FUNC(OCILobIsTemporary, clntsh, ocijdbc8) + AC_DEFINE(HAVE_OCI8_TEMP_LOB,1,[ ]) AC_DEFINE(HAVE_OCI8_SHARED_MODE,1,[ ]) @@ -107,12 +109,14 @@ 9.0) PHP_ADD_LIBRARY(clntsh, 1, OCI8_SHARED_LIBADD) -dnl This breaks build on some systems (AIX at least) -dnl if test -f $OCI8_DIR/lib/libocijdbc8.so ; then -dnl PHP_ADD_LIBRARY(ocijdbc8, 1, OCI8_SHARED_LIBADD) -dnl fi - PHP_ADD_LIBPATH($OCI8_DIR/lib, OCI8_SHARED_LIBADD) + + dnl Does not work with --with-oci8=shared on those + dnl systems (e.g. Tru64) where OCILobIsTemporary is found in + dnl libocijdbc8.so. + dnl + PHP_CHECK_FUNC(OCILobIsTemporary, clntsh, ocijdbc9) + AC_DEFINE(HAVE_OCI8_TEMP_LOB,1,[ ]) AC_DEFINE(HAVE_OCI8_ATTR_STATEMENT,1,[ ]) AC_DEFINE(HAVE_OCI8_SHARED_MODE,1,[ ]) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Using CLI as a shell
Marcus Börger [EMAIL PROTECTED] wrote: There is a difference between interactive mode and this idea. The idea was to execute every single line. So if you type 'echo Hello\n; and press enter Hello should be displayed. That's how it works for me (PHP-4.3.0). The only pitfall is that you need to use ?php: # php -a Interactive mode enabled ?php echo Hello\n; Hello Regards... Michael -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Using PHP for search and replace
Jean-Michel Dault [EMAIL PROTECTED] wrote: Currently, both Mandrake and RedHat use the following trick: perl -pi -e s|^;extension=mysql.so|extension=mysql.so| /etc/php.ini This sucks, because you then need perl to install a PHP extension. We sure could use sed, but this requires a temporary file, and this creates some security risks. Is there a quick and easy way to do this kind of thing in PHP? Or would this be something that we could integrate? And I know there's a new solution with the new config-file-scan-dir, but my question is a general search-and-replace solution. echo 'w php.ini.bak ,s/^; *extension=mysql.so/extension=mysql.so/ wq ' | ed php.ini /dev/null should do what you want. Regards... Michael -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Interesting result
In php.dev Markus Fischer [EMAIL PROTECTED] wrote: I was talking about telling the 'undefined behaviour' case; not what happens with the values exactly. I don't see a drawback in documenting an 'undefined behaviour'. It's good for people to have a torough documentation which even warns them before they're doing silly things. Note that the majority of users of PHP are non-programmers. Warning them before they shoot themselves a good thing [tm]. I think documenting this undefined behaviour is a good thing. Maybe something like this on language.operators.assignment.php: Assigning to a variable more than once in the same expression leads to undefined behaviour - this means you _might_ get the result you want, but this can change with the PHP version or the machine your code is running on, or even with the phase of the moon. Just don't do it. Don't do something like this: $b = ($a += 1) + ($a += 2); Instead use: $b = $a += 1; $b += ($a += 2); Between assignments to the same variable, always use a semicolon. If you're not sure about operator precedence, use parentheses. And almost the same on language.operators.increment.php: Incrementing or decrementing a variable more than once in the same expression leads to undefined behaviour - this means you _might_ get the result you want, but this can change with the PHP version or the machine your code is running on, or even with the phase of the moon. Just don't do it. Don't do something like this: $b = ($a++) + ($a++); Instead use: $b = $a++; $b += $a++; Between incrementing or decrementing the same variable, always use a semicolon. Regards... Michael -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: #20887 [Bgs-Ctl]: /php.ini
[EMAIL PROTECTED] wrote:
ID: 20887
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Bogus
+Status: Critical
-Bug Type: Unknown/Other Function
+Bug Type: Scripting Engine problem
Operating System: Mandrqke Linux 9.0
-PHP Version: 4.3.0RC2
+PHP Version: 4.3.0-dev
New Comment:
I just got bitten by this myself too. But it doesn't happen
with CLI for me, only with the Apache module.
Here (Linux) it happens with CLI if I start php without a path and have a
directory named php with a php-cli.ini.
In main/php_ini.c, the location of the executable is used to search the
php-*.ini:
if (sapi_module.executable_location) {
binary_location = estrdup(sapi_module.executable_location);
} else {
binary_location = NULL;
}
In php_cli.c, the executable_location is guessed [1] from argv[0], which can
be almost anything (although it happens to be the executable location
sometimes):
cli_sapi_module.executable_location = argv[0];
But do we really want to search the path of the executable for an ini file?
At least on Unix, that's a rather uncommon place for ini files. Since
this feature (searching the executable path) has not been advertised
anywhere yet, I suggest that it is removed at least for the Unix
versions (I can't speak for the other versions). The builtin path to
php*.ini, the PHPRC variable and the -c switch are quite enough places
to look for ini files, IMHO.
Regards...
Michael
[1]: see the entry in the Unix FAQ about argv[0]:
http://www.erlenstar.demon.co.uk/unix/faq_2.html#SEC23
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: #20673 [Opn-Ver]: Inexplicable arithmetical error due to references
[EMAIL PROTECTED] wrote in php.bugs: [2002-11-27 07:04:52] [EMAIL PROTECTED] ? $a = 7; $a = $a + $a++; echo $a; //the result is 14; ? When I add a reference to $a, the behavior of $a + $a++ becomes inexplicable different. Note that $a isn't changed anywhere! ? $a = 7; $b = $a; $a = $a + $a++; echo $a; //the result is 15; ? The only difference is $b = $a, but why $a takes care of references to itself? Ilia verified the bug, and I can reproduce that behaviour here as well. But I'm not sure whether the expressions $a = $a + $a++; or $x = $a + $a++; really are valid/legal/well-defined expressions. When exactly is that $a++ meant to be interpreted/executed? Before or after that other $a is looked at? I know that PHP is not C, but hasn't that something to do with sections 3.1 to 3.3 of the C FAQ, http://www.eskimo.com/~scs/C-faq/s3.html? Regards... Michael -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: #20596 [Opn-Bgs]: date function gives wrong result for format 't'
Derick Rethans [EMAIL PROTECTED] wrote: On Sat, 23 Nov 2002, Melvyn Sopacua wrote: So ehm - are Michael and Derick on a 'date' or what? At 16:57 23-11-2002, [EMAIL PROTECTED] wrote: http://bugs.php.net/?id=20596edit=1 http://bugs.php.net/?id=20592edit=1 http://bugs.php.net/?id=20594edit=1 No, but Michael has no account to close the bogus reports :) True - just trying to answer the easy ones, so the PHP developers can save some time. Regards... Michael -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ext/standard/tests/math/log.phpt coredump on Tru64
Pollita [EMAIL PROTECTED] wrote:
log(0) in any base (except 0, which would be silly) is an undefined
number.
Yes, that's what the teachers told us before they admitted the existance
of infinity.
the libc log() function will return an exceedingly small number
to avoid causing widepsread panic when log(0) is attempted
(-1.7976931348623E+308 shown below).
Are you sure?
% cat log.c
#include stdio.h
#include math.h
int main()
{
printf(%g\n,log(0));
}
% gcc log.c -o log -lm
% ./log
-inf
That's on Linux. On Tru64, it prints:
-1.79769e+308
The test function for log:
$x2 = (int) pow($base, log($x, $base));
attempts to check that $x2 is close to $x, but since log(0,*) will return
an excessively small number, pow() winds up choking.
Suggest: $x2 = (int) log(pow($x,base),$base); instead.
Thanks for the suggestion, but it dumps core nevertheless:
% sapi/cli/php -r 'echo log(pow(0,2),2),\n;'
Floating point exception (core dumped)
% sapi/cli/php -r 'echo log(0,2),\n;'
Floating point exception (core dumped)
P.S. example below using log in base 1 is also nonsensical... only
log(1,1) is a valid use of log with a base parameter of 1, any other value
results in undefined
Umm, yes, maybe - but my point was that PHP should not dump core in such
situations, and it certainly should not do so in a make test (Wait a
minute, what's that core file here? And now you want me to 'make
install'?!).
Regards...
Michael
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ext/standard/tests/math/log.phpt coredump on Tru64
I wrote:
% cat log.c
#include stdio.h
#include math.h
int main()
{
printf(%g\n,log(0));
}
% gcc log.c -o log -lm
% ./log
-inf
That's on Linux. On Tru64, it prints:
-1.79769e+308
Apparently, there's a compiler switch to make it behave like on Linux:
% cc -ieee log.c -o log -lm
% ./log
-INF
man cc says:
-ieee
Ensure support of all portable features of the IEEE Standard for Binary
Floating-Point Arithmetic (ANSI/IEEE Std 754-1985), including the
treatment of denormalized numbers, NaNs, and infinities and the han-
dling of error cases. This option also sets the _IEEE_FP C preprocessor
macro.
For gcc, the same switch is named -mieee.
When PHP is compiled with -ieee, the log.phpt PASSes. Although the other
tests are not affected by -ieee, I guess it's a bit too late to
automatically add it for 4.3.0.
Regards...
Michael
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: #19259 [Csd-Ctl]: sort-functions don't work
[EMAIL PROTECTED] wrote:
ID: 19259
Updated by: [EMAIL PROTECTED]
-Summary: usort() leaves array unsorted
Reported By: [EMAIL PROTECTED]
-Status: Closed
+Status: Critical
Bug Type: Arrays related
-Operating System: OSF1 V4.0 1229
+Operating System: OSF1 V4.0
-PHP Version: 4.2.2
+PHP Version: 4.3.0 RC1
[...]
EXPECTED OUTPUT
-- Testing arsort() --
No second argument:
array(8) {
[-2147483647]=
array(2) {
[0]=
string(6) banana
[1]=
string(6) orange
}
[test]=
int(27)
[2147483647]=
string(4) test
[-2147483648]=
string(6) monkey
[...]
ACTUAL OUTPUT
-- Testing arsort() --
No second argument:
array(8) {
[-2147483647]=
array(2) {
[0]=
string(6) banana
[1]=
string(6) orange
}
[test]=
int(27)
[2147483647]=
string(4) test
[2147483648]=
string(6) monkey
These test results scared me as well, but it looks like this array test
itsself is flawed: it relies on the fact that integers automatically
wrap around to negative values at INT_MAX (=2147483647 on 32 bit
machines). Have a look at the unsorted data in data.inc:
On Linux/Intel (32 bit integers):
# sapi/cli/php -r 'include(ext/standard/tests/array/data.inc); var_dump($data);'
array(8) {
[0]=
string(3) PHP
[17]=
string(27) PHP: Hypertext Preprocessor
[5]=
string(4) Test
[test]=
int(27)
[2147483647]=
string(4) test
[-2147483647]=
array(2) {
[0]=
string(6) banana
[1]=
string(6) orange
}
[-2147483648]=
string(6) monkey
[16777216]=
float(-0.33)
}
On Tru64/Alpha (64 bit integers):
# sapi/cli/php -r 'include(ext/standard/tests/array/data.inc); var_dump($data);'
Unaligned access pid=156100 php va=0x1400510cc pc=0x12019ab50 ra=0x12019ab44
inst=0xb401
Unaligned access pid=156100 php va=0x14005272c pc=0x12019ab50 ra=0x12019ab44
inst=0xb401
array(8) {
[0]=
string(3) PHP
[17]=
string(27) PHP: Hypertext Preprocessor
[5]=
string(4) Test
[test]=
int(27)
[2147483647]=
string(4) test
[-2147483647]=
array(2) {
[0]=
string(6) banana
[1]=
string(6) orange
}
[2147483648]=
string(6) monkey
[16777216]=
float(-0.33)
}
The difference is in the key of the monkey element: it should be
2147483647+1, but on 32 bit machines, this number is automatically
wrapped and so it results in -2147483648. On 64 bit machines,
2147483647+1 correctly results in +2147483648, so it's impossible to get
the expected result there.
Regards...
Michael
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: #19259 [Csd-Ctl]: sort-functions don't work
I wrote:
These test results scared me as well, but it looks like this array
test itsself is flawed: it relies on the fact that integers
automatically wrap around to negative values at INT_MAX (=2147483647
on 32 bit machines).
Attaching a patch for the array test: I changed the array in data.inc
to have only normal values (1000 and -1000) instead of 2147483647 and
-2147483647, and used the output of the tests on a 32 bit Linux machine
to be the expected result. With the patch, all three tests PASSed on the
64 bit Tru64 machine. So array sorting is fortunately not broken again
on Tru64.
Regards...
Michael
diff -r -u ../php-cvs/php4/ext/standard/tests/array/001.phpt
ext/standard/tests/array/001.phpt
--- ../php-cvs/php4/ext/standard/tests/array/001.phpt Sat Nov 9 11:42:49 2002
+++ ext/standard/tests/array/001.phpt Sat Nov 16 16:08:01 2002
@@ -57,7 +57,7 @@
int(27)
[3]=
string(4) test
- [-2147483647]=
+ [-1000]=
array(2) {
[0]=
string(6) banana
@@ -113,7 +113,7 @@
int(27)
int(3)
string(4) test
-string(11) -2147483647
+string(5) -1000
array(2) {
[0]=
string(6) banana
diff -r -u ../php-cvs/php4/ext/standard/tests/array/002.phpt
ext/standard/tests/array/002.phpt
--- ../php-cvs/php4/ext/standard/tests/array/002.phpt Sat Nov 9 11:42:49 2002
+++ ext/standard/tests/array/002.phpt Sat Nov 16 16:07:14 2002
@@ -24,16 +24,43 @@
var_dump ($data);
}
+echo Unsorted data:\n;
+var_dump ($data);
foreach (array ('arsort', 'asort', 'krsort', 'ksort', 'rsort', 'sort') as
$test_function) {
test_sort ($test_function, $data);
}
?
--EXPECT--
--- Testing arsort() --
+Unsorted data:
+array(8) {
+ [0]=
+ string(3) PHP
+ [17]=
+ string(27) PHP: Hypertext Preprocessor
+ [5]=
+ string(4) Test
+ [test]=
+ int(27)
+ [1000]=
+ string(4) test
+ [-1000]=
+ array(2) {
+[0]=
+string(6) banana
+[1]=
+string(6) orange
+ }
+ [1001]=
+ string(6) monkey
+ [16777216]=
+ float(-0.33)
+}
+
+ -- Testing arsort() --
No second argument:
array(8) {
- [-2147483647]=
+ [-1000]=
array(2) {
[0]=
string(6) banana
@@ -42,9 +69,9 @@
}
[test]=
int(27)
- [2147483647]=
+ [1000]=
string(4) test
- [-2147483648]=
+ [1001]=
string(6) monkey
[5]=
string(4) Test
@@ -57,7 +84,7 @@
}
Using SORT_REGULAR:
array(8) {
- [-2147483647]=
+ [-1000]=
array(2) {
[0]=
string(6) banana
@@ -66,9 +93,9 @@
}
[test]=
int(27)
- [2147483647]=
+ [1000]=
string(4) test
- [-2147483648]=
+ [1001]=
string(6) monkey
[5]=
string(4) Test
@@ -83,7 +110,7 @@
array(8) {
[test]=
int(27)
- [-2147483647]=
+ [-1000]=
array(2) {
[0]=
string(6) banana
@@ -94,20 +121,20 @@
string(3) PHP
[17]=
string(27) PHP: Hypertext Preprocessor
- [-2147483648]=
+ [1001]=
string(6) monkey
[5]=
string(4) Test
- [2147483647]=
+ [1000]=
string(4) test
[16777216]=
float(-0.33)
}
Using SORT_STRING
array(8) {
- [2147483647]=
+ [1000]=
string(4) test
- [-2147483648]=
+ [1001]=
string(6) monkey
[5]=
string(4) Test
@@ -115,7 +142,7 @@
string(27) PHP: Hypertext Preprocessor
[0]=
string(3) PHP
- [-2147483647]=
+ [-1000]=
array(2) {
[0]=
string(6) banana
@@ -139,13 +166,13 @@
string(27) PHP: Hypertext Preprocessor
[5]=
string(4) Test
- [-2147483648]=
+ [1001]=
string(6) monkey
- [2147483647]=
+ [1000]=
string(4) test
[test]=
int(27)
- [-2147483647]=
+ [-1000]=
array(2) {
[0]=
string(6) banana
@@ -163,13 +190,13 @@
string(27) PHP: Hypertext Preprocessor
[5]=
string(4) Test
- [-2147483648]=
+ [1001]=
string(6) monkey
- [2147483647]=
+ [1000]=
string(4) test
[test]=
int(27)
- [-2147483647]=
+ [-1000]=
array(2) {
[0]=
string(6) banana
@@ -181,9 +208,9 @@
array(8) {
[16777216]=
float(-0.33)
- [-2147483648]=
+ [1001]=
string(6) monkey
- [2147483647]=
+ [1000]=
string(4) test
[5]=
string(4) Test
@@ -191,7 +218,7 @@
string(27) PHP: Hypertext Preprocessor
[0]=
string(3) PHP
- [-2147483647]=
+ [-1000]=
array(2) {
[0]=
string(6) banana
@@ -207,7 +234,7 @@
float(-0.33)
[test]=
int(27)
- [-2147483647]=
+ [-1000]=
array(2) {
[0]=
string(6) banana
@@ -220,19 +247,21 @@
string(27) PHP: Hypertext Preprocessor
[5]=
string(4) Test
- [-2147483648]=
+ [1001]=
string(6) monkey
- [2147483647]=
+ [1000]=
string(4) test
}
-- Testing krsort() --
No second argument:
array(8) {
- [2147483647]=
- string(4) test
[16777216]=
float(-0.33)
+ [1001]=
+ string(6) monkey
+ [1000]=
+ string(4) test
[17]=
string(27) PHP: Hypertext Preprocessor
[5]=
@@ -241,46 +270,46 @@
int(27)
[0]=
string(3) PHP
- [-2147483647]=
+ [-1000]=
array(2) {
[0]=
string(6) banana
[1]=
string(6) orange
}
-
Re: [PHP-DEV] Re: #19259 [Csd-Ctl]: sort-functions don't work
Marcus Börger [EMAIL PROTECTED] wrote:
Thanks it looks good - applied.
Thanks, great.
While we're at it, there's another test which fails on 64 bit machines
and can easily be fixed:
var_dump float test [ext/standard/tests/general_functions/008.phpt]
This test fails because 123456789012 and 1234567890120 are PHP integers
on 64 bit machines:
EXPECTED OUTPUT
[...]
[11]=
float(123456789012)
[12]=
float(1234567890120)
ACTUAL OUTPUT
[...]
[11]=
int(123456789012)
[12]=
int(1234567890123)
The fix:
--- ext/standard/tests/general_functions/008.phpt~ Wed Aug 21 03:27:56 2002
+++ ext/standard/tests/general_functions/008.phpt Sun Nov 10 22:50:29 2002
@@ -5,7 +5,7 @@
--FILE--
?php
// this checks f,g,G conversion for snprintf/spprintf
-var_dump(array(ini_get('precision'),.012,-.012,.12,-.12,1.2,-1.2,12.,-12.,0.000123,.123,123456789012,1234567890123,12345678901234567890));
+var_dump(array(ini_get('precision'),.012,-.012,.12,-.12,1.2,-1.2,12.,-12.,0.000123,.123,123456789012,(float)1234567890123,(float)12345678901234567890));
?
--EXPECT--
array(14) {
Regards...
Michael
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: : sort-functions don't work
Marcus Börger wrote: Ups one missing: cvs -z3 -q diff 008.phpt (in directory S:\php4-HEAD\ext\standard\tests\general_functions\) Index: 008.phpt === RCS file: /repository/php4/ext/standard/tests/general_functions/008.phpt,v retrieving revision 1.1 diff -u -r1.1 008.phpt --- 008.phpt21 Aug 2002 01:27:56 - 1.1 +++ 008.phpt16 Nov 2002 19:31:34 - Yes, this works! Regards... Michael -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] ext/standard/tests/math/log.phpt coredump on Tru64
Hi, php4-STABLE-200211152030 dumps core on Tru64/Alpha with ext/standard/tests/math/log.phpt: EXPECTED OUTPUT On failure, please mail result to [EMAIL PROTECTED] 200 50 50 50 50 50 50 50 50 50 ACTUAL OUTPUT On failure, please mail result to [EMAIL PROTECTED] 200 FAILED Looking which values it doesn't like: # sapi/cli/php -r 'echo log(0, 2),\n;' Floating point exception (core dumped) # sapi/cli/php -r 'echo log(0, 3),\n;' -1.6363308087894E+308 # sapi/cli/php -r 'echo log(0, 10),\n;' -7.8072820862606E+307 # sapi/cli/php -r 'echo log(0, 1),\n;' Floating point exception (core dumped) # sapi/cli/php -r 'echo log(0),\n;' -1.7976931348623E+308 Regards... Michael -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Patch for ext/standard/tests/time/001.phpt
ext/standard/tests/time/001.phpt fails on Tru64, because the
gettimeofday(2) C library function has not enough granularity in the
standard configuration.
http://www2.tru64.org/pages.php?page=Tru64-FAQ-Programming says that
the clock's granularity is 1024 Hz normally, but can be increased by
rebuilding the kernel. But that shouldn't be of any concern for PHP or
for this test. Maybe a sentence about that should be added to the PHP
manual, e.g. something like: Although this function returns
microseconds, this doesn't necessarily mean that your system library
actually delivers such a high granularity.
--- ext/standard/tests/time/001.phpt~ Fri Nov 15 10:25:59 2002
+++ ext/standard/tests/time/001.phptSat Nov 16 18:41:56 2002
@@ -14,7 +14,7 @@
for ($i=1;$i=10;$i++) {
list($micro,$time)=explode( ,microtime());
- if ($time $last_t || ($time == $last_t $micro $last_m)) {
+ if ($time $last_t || ($time == $last_t $micro = $last_m)) {
$passed++;
} else if ($failed++ =10) {
$result .= sprintf('%06d', $i).: $time $micro $last_t $last_m\n;
Regards...
Michael
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Patch for ext/standard/tests/math/hexdec.phpt
The hexdec test fails on 64 bit machines, because two big numbers still fit into a PHP integer (on 32 bit, these are automatically converted into floats): /house/elmicha/local/src/php4-STABLE-200211152030/ext/standard/tests/math/hexdec.phpt EXPECTED OUTPUT int(74565) int(74565) int(74565) int(74565) int(74565) float(78187069441) float(6442450943) ACTUAL OUTPUT int(74565) int(74565) int(74565) int(74565) int(74565) int(78187069441) int(6442450943) FAILED 006- float(78187069441) 006+ int(78187069441) 007- float(6442450943) 007+ int(6442450943) Patch: --- ext/standard/tests/math/hexdec.phpt~Thu Oct 3 22:34:15 2002 +++ ext/standard/tests/math/hexdec.phpt Sat Nov 16 19:38:30 2002 @@ -8,8 +8,8 @@ var_dump(hexdec(q12345)); var_dump(hexdec(12345+?!)); var_dump(hexdec(12345q)); -var_dump(hexdec(123451)); -var_dump(hexdec(17fff)); +var_dump((float)hexdec(123451)); +var_dump((float)hexdec(17fff)); ? --EXPECT-- Regards... Michael -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PATCH] run-tests.php
Melvyn Sopacua [EMAIL PROTECTED] wrote: At 19:02 1-11-2002, John Coggeshall wrote: I haven't looked at the patch in great detail, can someone forward me The commitlog? It hasn't been committed yet, as we agreed that only persons in 'Authors' should do that and agree, otherwise it'll be a mess. May I kindly ask that someone commits the patch, please? An option to send the test results manually, without trying to upload it, would be really useful. E.g. at my working place the machines are not directly connected to the Internet, and repeatedly banging against the firewall might be seen a bit annoying by the admins. And in some environments (e.g. on the HP/Compaq test drives), mail_qa_team() posts to nowhere land and nevertheless reports success. The patch is also not very large, and I've seen no real objections against including it. Regards... Michael -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/xml/tests 007.phpt
I wrote about fun with locales, but forgot to mention the user notes at http://www.php.net/manual/de/function.setlocale.php. Some users note that they have to use Dutch on their Windows (?) systems. So if we really need the locale guessing, we probably should add German as well (and hope that the locale string is not localized in some versions of Windows). Regards... Michael -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/xml/tests 007.phpt
Derick Rethans [EMAIL PROTECTED] wrote:
On Mon, 21 Oct 2002, Melvyn Sopacua wrote:
msopacua Mon Oct 21 04:55:07 2002 EDT
Modified files:
/php4/ext/xml/tests 007.phpt
Log:
Skip this when strtoupper doesn't behave as expected, because casefolding
depends on this.
erm, this is just a local problem. Just set the locale to German here
and it will work just fine I think. IMO this is a hack :)
The problem is that there are an awful lot of German locales.
Something like
setlocale(LC_ALL,array('de_DE.ISO8859-1','de_DE.ISO8859-15',
'de_DE@euro','de','de_DE'));
and some more variations with - or _ after the ISO, or even DIS
instead of ISO, might work for most platforms that have a German
locale installed. But because some systems don't have a German locale at
all (IIRC on Debian you have to install your locales explicitly and run
locale-gen afterwards), en_US and it's variations might be more
promising:
foreach(array('','_','-') as $hyphen)
foreach(array('ISO','DIS') as $ISODIS)
$locales[] = en_US.${ISODIS}${hyphen}8859-1\n;
$locales[] = 'en_US@euro';
$locales[] = 'en_US';
$locales[] = 'en';
setlocale(LC_ALL,$locales);
Nice, isn't it?
There's a good page about that at
http://www.uni-ulm.de/~s_smasch/locale/ (in English). There's also a
small C program called checklocale.
But even if we use such a locale guessing: it's not the fault of the XML
code if non-ASCII characters don't work. It might be a good idea to have
a seperate test case for strtoupper() etc., but for testing the XML
extension, I still think that's it's better to just bail out as soon as
we see that strtoupper() doesn't behave.
Maybe we should add
setlocale(LC_ALL,'');
at the beginning of ext/xml/tests/007.phpt to make sure that the locale
settings of the environment are used (although here the values of the
environment are used even without that statement).
Regards...
Michael
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-QA] Logs of failed tests PHP 4.3.0pre1 (fwd)
Mike Robinson [EMAIL PROTECTED] wrote: Michael Mauch writes: Are your locale settings ok? Yeah, they're fine, for my locale. But I'm not in Germany, though I'm told the beer there is awesome. :) Yes, I'm told so, too ;-) I doubt that the C library does anything useful with non-ASCII characters while you are in a C or POSIX locale, so expat or PHP can't do much to correct that. So is your locale something other than C or POSIX? en_US.ISO-8859-1 for example? Perhaps ext/xml/tests/007.phpt could check whether it is able to successfully use strtoupper() on $xmldata - and if not, just skip that test? Regards... Michael -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-QA] Logs of failed tests PHP 4.3.0pre1 (fwd)
Melvyn Sopacua [EMAIL PROTECTED] wrote:
At 18:48 20-10-2002, Mike Robinson wrote:
Michael Mauch wrote:
I doubt that the C library does anything useful with
non-ASCII characters while you are in a C or POSIX
locale, so expat or PHP can't do much to correct that.
So is your locale something other than C or POSIX?
en_US.ISO-8859-1 for example?
Yup, thats what its set to.
Hmm. Strange. What does
php -r 'echo strtoupper(äöü),\n;'
yield on your system? And what system is it, btw?
Perhaps ext/xml/tests/007.phpt could check whether it is able
to successfully use strtoupper() on $xmldata - and if not,
just skip that test?
I have no problem with this test failing. It actually provides
useful information. I'm not one to second-guess the intentions
of the author of this test ('sniper' I think).
But the reason for failure is not very clear, plus the manual
(http://www.php.net/manual/en/ref.xml.php#xml.case-folding) makes
no mention of the fact that it may fail and/or why.
Yes, that's true.
Using non-ascii chars for tags, doesn't fall into the 'best practice'
category for me, but opinions differ :)
We could make strtoupper locale aware, with an optional argument
charset, but even then it can fail (tried it).
Umm, strtoupper() _is_ locale aware, at least here (Linux, glibc-2.1.3):
% php -r 'echo strtoupper(äöü),\n;'
ÄÖÜ
% LC_CTYPE=C php -r 'echo strtoupper(äöü),\n;'
äöü
We could use a test like strtopper(äöü)==ÄÖÜ to check if the system
is able to handle these characters correctly. If not, the test could be
skipped.
Alas it's not possible to use setlocale() and set it to a 100% good
locale with ISO-8859-1 characters - these bloody locales are different
on each system, so you can only try and guess (of course you can do set
right for your system(s), but not for _all_ systems). Obviously that
problem has been addressed by a kind soul who implemented an array
argument for setlocale() recently - see
http://www.php.net/manual/en/function.setlocale.php. The user notes
there are also very informative.
What would be nice - in general - is a skip reason.
Yes, true.
Regards...
Michael
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-QA] Logs of failed tests PHP 4.3.0pre1 (fwd)
Mike Robinson [EMAIL PROTECTED] wrote: Sorry, that test _is_ in 4.2.3, and it failed there as well with the same problem, it just didn't output anything during make test. Are your locale settings ok? % locale LANG=de_DE.ISO-8859-15 LC_CTYPE=de_DE LC_NUMERIC=de_DE.ISO-8859-15 LC_TIME=de_DE.ISO-8859-15 LC_COLLATE=C LC_MONETARY=de_DE.ISO-8859-15 LC_MESSAGES=de_DE.ISO-8859-15 LC_ALL= % php ./run-tests.php ext/xml/tests/007.phpt = CWD : /usr/local/src/php-cvs/php4 PHP : sapi/cli/php PHP_SAPI: cli PHP_VERSION : 4.3.0-dev PHP_OS : Linux INI actual : /usr/local/lib/php.ini More .INIs : Extra dirs : = Running selected tests. PASS xml_parse_into_struct/umlauts in tags [ext/xml/tests/007.phpt] % LC_ALL=C php ./run-tests.php ext/xml/tests/007.phpt = CWD : /usr/local/src/php-cvs/php4 PHP : sapi/cli/php PHP_SAPI: cli PHP_VERSION : 4.3.0-dev PHP_OS : Linux INI actual : /usr/local/lib/php.ini More .INIs : Extra dirs : = Running selected tests. FAIL xml_parse_into_struct/umlauts in tags [ext/xml/tests/007.phpt] Regards... Michael -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard config.m4 css.c css.h info.c /main php_ini.c /sapi/aolserver aolserver.c /sapi/apache php_apache.c
Michael Mauch [EMAIL PROTECTED] wrote: Colin Viebrock [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: render nicely is something else than total unreadable to me. Did you have a look at it with Netscape Navigator 4? Please fix something for it, as it's pretty horrible now. Can you send me a screen grab? I did test it under NS 4.7 (Win), and I think you're exaggerating a bit, because it's hardly unreadable. With Netscape 4.7x on Linux and Windows, I see a lot of vertical whitespace in some places, e.g. directly after PHP Core there's a screen full of nothing. Please disregard my previous post - your current version 1.22 of css.c looks great, at least in Netscape 4.x, Opera 6.0 and Mozilla 1.2a on Linux. Regards... Michael -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] #18640: compilation with Oracle fails on Tru64
Hi, http://bugs.php.net/bug.php?id=18640 describes the problem that some Oracle versions (patch levels) on Tru64 seem to have some OCILob* functions in the libocijdbc8 library instead of in the usual libclntsh. This makes the PHP build fail with unresolved symbols. http://bugs.php.net/bug.php?id=14193 also seems to be related. Although this seems to be all Oracle's fault, I suggest to link against libocijdbc8 if it is available. I tested the patch below with Oracle 8.1.7 and 9.0.1 on Tru64 5.1, Oracle 8.1.6 on Tru64 4.0f, Oracle 8.1.7 on Solaris 7, and with Oracle 8.1.6 on Linux/ix86. Only the Oracle 8.1.x on Tru64 needed the patch, but I wanted to make sure that the additional library does no harm to the others. The patch also applies cleanly against 4.2.3, and against the current CVS version (HEAD) if you use --ignore-whitespace (GNU patch). Can somebody please add this? If this is not the right way to send a patch, please tell me. Regards... Michael --- php4-STABLE-200209050900/ext/oci8/config.m4.origFri Nov 30 19:59:46 2001 +++ php4-STABLE-200209050900/ext/oci8/config.m4 Fri Sep 6 16:23:01 2002 -68,6 +68,9 8.1|9.0) PHP_ADD_LIBRARY(clntsh, 1, OCI8_SHARED_LIBADD) + if test -f $OCI8_DIR/lib/libocijdbc8.so ; then + PHP_ADD_LIBRARY(ocijdbc8, 1, OCI8_SHARED_LIBADD) + fi PHP_ADD_LIBPATH($OCI8_DIR/lib, OCI8_SHARED_LIBADD) AC_DEFINE(HAVE_OCI8_TEMP_LOB,1,[ ]) ;; -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] header(Content-type: text/...) with default_charset
Hi,
header(Content-type: text/plain) or header(Content-type: text/xml)
does not work as soon as a default_charset is enabled in php.ini.
I reported that in http://bugs.php.net/bug.php?id=19098 a week ago,
but nobody answered yet. This bug is still there in php-4.2.3RC2.
If you use the mod_php version with Apache, you will get Content-type:
text/html if you use header(Content-type: text/plain) or
header(Content-type: text/xml).
Here's a small test script (header_test.php) to show the problem. It
calls the CGI version of php (in the current directory) and tries a few
Content-type headers:
?
$PHP = ./php -c .;
$Headers = array(Content-type: text/plain,
Content-type: text/xml,
Content-type: application/xml,
Content-type:text/plain,
Content-type:text/plain ,
Content-type:text/longertextsubtype,
Content-type: text/plain;charset=iso-8859-1,
Content-type: text/plain; charset=UTF-8);
foreach($Headers as $Header)
{
$Cmd = echo \?php header('$Header') ?\ | $PHP ;
unset($Output);
exec($Cmd, $Output);
print Header: \$Header\\nOutput: \$Output[1]\\n\n;
}
?
The output of that script:
# ./php -c . -q header_test.php
Header: Content-type: text/plain
Output: Content-type
Header: Content-type: text/xml
Output: Content-type
Header: Content-type: application/xml
Output: Content-type: application/xml
Header: Content-type:text/plain
Output: Content-type
Header: Content-type:text/plain
Output: Content-type
Header: Content-type:text/longertextsubtype
Output: Content-type
Header: Content-type: text/plain;charset=iso-8859-1
Output: Content-type: text/plain;charset=iso-8859-1
Header: Content-type: text/plain; charset=UTF-8
Output: Content-type: text/plain; charset=UTF-8
So if you don't explicitly set the charset, like in the last two tests,
the output is wrong.
A small patch that makes this right in most cases:
# diff -u php-4.2.3RC2/main/SAPI.c.orig php-4.2.3RC2/main/SAPI.c
--- php-4.2.3RC2/main/SAPI.c.orig Sat Jul 27 15:15:42 2002
+++ php-4.2.3RC2/main/SAPI.cWed Sep 4 19:07:50 2002
-261,11 +261,12
newtype = emalloc(newlen + 1);
PHP_STRLCPY(newtype, *mimetype, newlen + 1, len);
strlcat(newtype, ;charset=, newlen + 1);
+ strlcat(newtype, charset, newlen + 1);
if (*mimetype != NULL) {
efree(*mimetype);
}
*mimetype = newtype;
- return newlen;
+ return newlen - 1;
}
return 0;
}
-461,7 +462,7
sapi_header.header = newheader;
sapi_header.header_len = newlen - 1;
colon_offset = strchr(newheader, ':');
- *colon_offset = '\0';
+ /* *colon_offset = '\0'; */
efree(header_line);
}
The test script output after this patch has been applied:
# ./php -c . -q header_test.php
Header: Content-type: text/plain
Output: Content-type: text/plain;charset=iso-8859-1
Header: Content-type: text/xml
Output: Content-type: text/xml;charset=iso-8859-1
Header: Content-type: application/xml
Output: Content-type: application/xml
Header: Content-type:text/plain
Output: Content-type: text/plain;charset=iso-8859-
Header: Content-type:text/plain
Output: Content-type: text/plain;charset=iso-8859-
Header: Content-type:text/longertextsubtype
Output: Content-type: text/longertextsubtype;charset=iso-8859-
Header: Content-type: text/plain;charset=iso-8859-1
Output: Content-type: text/plain;charset=iso-8859-1
Header: Content-type: text/plain; charset=UTF-8
Output: Content-type: text/plain; charset=UTF-8
Only the cases without a space after the colon are still garbled.
RFC 2616, section 4.2, says: The field value MAY be preceded by any
amount of LWS, though a single SP is preferred.
So people should be able to use header(Content-type:text/plain) as
well, but I can't find the remaining bug.
Any comments, please?
Regards...
Michael
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 4.0 Bug #9536: date(br) gives wrong output
From: [EMAIL PROTECTED]
Operating system: Linux, Win98, Win2k
PHP version: 4.0.4pl1
PHP Bug Type: Date/time related
Bug description: date("lt;brgt;") gives wrong output
Variations of date("br") returns wrong output or lets PHP
dump core. This bug has been reported by Christian Hamacher
in de.comp.lang.php, followups reported similar problems on
Win 98 and Win 2000.
Here on Linux 2.4.2 I see:
% echo '?
$Date=date("d.m.Y br H:i:s");
echo "$Date\n";
?' | php -q
03.03.2001 bSat, 3 Mar 2001 12:16:42 +0100
808132658:876230193:976367904
No core dump here if I run in the Bash, but wrong output.
In zsh, I get a core dump (and the wrong output):
% echo '?
$Date=date("d.m.Y br H:i:s");
echo "$Date\n";
?' | php -q
03.03.2001 bSat, 3 Mar 2001 12:20:05 +0100
808132661:809119794:976367904
zsh: done echo ?
$Date=date("d.m.Y br H:i:s");
echo "$Date\n";
? |
zsh: segmentation fault (core dumped) php -q
% gdb =php core
GNU gdb 4.17.0.11 with Linux support
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public
License, and you are
welcome to change it and/or distribute copies of it under
certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show
warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...
Core was generated by `php -q'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libdl.so.2...done.
Reading symbols from /usr/local/lib/libz.so.1...done.
Reading symbols from /usr/local/lib/libreadline.so.4.1...done.
Reading symbols from /usr/local/lib/libhistory.so.4.1...done.
Reading symbols from /lib/libncurses.so.5...done.
Reading symbols from /usr/lib/libttf.so.2...done.
Reading symbols from /usr/local/lib/libpng.so.2...done.
Reading symbols from /usr/X11R6/lib/libX11.so.6...done.
Reading symbols from /usr/X11R6/lib/libXpm.so.4...done.
Reading symbols from /usr/local/lib/libjpeg.so.62...done.
Reading symbols from /usr/local/lib/libxml.so.2...done.
Reading symbols from /usr/lib/libgdbm.so.1...done.
Reading symbols from /usr/local/lib/libcurl.so.0...done.
Reading symbols from /lib/libresolv.so.2...done.
Reading symbols from /lib/libm.so.6...done.
Reading symbols from /lib/libcrypt.so.1...done.
Reading symbols from /lib/libnsl.so.1...done.
Reading symbols from /lib/libc.so.6...done.
Reading symbols from /lib/ld-linux.so.2...done.
Reading symbols from /lib/libnss_db.so.2...done.
Reading symbols from /lib/libdb.so.3...done.
Reading symbols from /lib/libnss_files.so.2...done.
#0 chunk_free (ar_ptr=0x403b8220, p=0x8267070) at malloc.c:3049
malloc.c:3049: No such file or directory.
(gdb) bt
#0 chunk_free (ar_ptr=0x403b8220, p=0x8267070) at malloc.c:3049
#1 0x4032e14a in __libc_free (mem=0x8267078) at malloc.c:3023
#2 0x80ed001 in _efree (ptr=0x8267084) at zend_alloc.c:238
#3 0x80e1ec9 in zend_hash_destroy (ht=0x826192c) at
zend_hash.c:569
#4 0x80f1950 in shutdown_executor () at zend_execute_API.c:165
#5 0x80e48e4 in zend_deactivate () at zend.c:525
#6 0x8072ca2 in php_request_shutdown (dummy=0x0) at main.c:688
#7 0x806faff in main (argc=2, argv=0xb2ac) at
cgi_main.c:771
#8 0x402f58c1 in __libc_start_main (main=0x806f30c main,
argc=2,
argv=0xb2ac, init=0x806d3f8 _init, fini=0x819b2a4
_fini,
rtld_fini=0x4000a914 _dl_fini, stack_end=0xb2a4)
at ../sysdeps/generic/libc-start.c:92
(gdb)
If I ask for a "b" instead for "br", everything is ok.
Of course there are easy work-arounds (just use `echo
"br"' instead), but nevertheless.
Regards...
Michael
--
Edit Bug report at: http://bugs.php.net/?id=9536edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
