[PHP-DEV] Autoload possibly? (was: set_error_handler() not handling E_ERROR)
As Rasmus said, we discussed this issue lately. We agreed that errors that
can't be handled automatically (fatal errors), but don't leave the
scripting engine in an unstable state, should be allowed to be handled by
users. The example there was also calls to undefined functions.
Unfortunately, calls to undefined functions do (or may) leave the engine in
an unstable state, as far as I recall. I didn't get to review the code
since then - so it may or may not be safe to let users trap this error.
At any rate, we won't use E_USER_ERROR for this type of fatal, yet
recoverable errors - but a new error level (E_TRAPPABLE_ERROR or something
like that).
This probably sounds kind of hackish (and off topic for the current
thread) but if you were to allow users to catch undefined functions, would
it be possible to then also allow the error handler to return a value to
be returned to the caller of said undefined function? It's basically a
rather hackish method of allowing autoload of includes/libraries,
something to the effect of:
function error_handler($errno,$errmsg,$file,$line,$fcall,$args)
{
if ($errno == E_UNDEFINED_FUNCTION) {
// You get the idea here ...
if (find_function_in_autoload_stuff($fcall))
return call_user_function_array($fcall,$args);
else
print_error_message();
} else {
do_other_stuff();
}
}
set_error_handler("error_handler");
$a = undefined_function(); /* Now if the error handler can find the
function, it transparently loads the
required files and the script never
notices the difference. Otherwise,
we never execute beyond this point. */
I know that my example is horribly oversimplified, but it should get the
point across..
Chris
--
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]
Re: [PHP-DEV] MySQL client library upgrade: 3.3.31
On Wed, 17 Jan 2001, Thimble Smith wrote: On Wed, Jan 17, 2001 at 01:57:08AM -0800, [EMAIL PROTECTED] wrote: +AC_DEFUN(PHP_MYSQL_VERSION,[ + if test "$PHP_MYSQL" != "yes"; then +AC_MSG_CHECKING(for MySQL version) +MYSQL_VERSION=$( strings $MYSQL_LIB_DIR/libmysqlclient.so | grep '3\.' ) +if test "x$( echo $MYSQL_VERSION | cut -f2 -d. )" = "x23" ; then + AC_MSG_RESULT($MYSQL_VERSION) + PHP_EVAL_LIBLINE($PHP_MYSQL/bin/mysql_config --libs) +else + AC_MSG_RESULT($MYSQL_VERSION) +fi + fi +]) I think it would be better to simply check if mysql_config exists. If so, use it; if not, assume that the version is older and doesn't need -lz. One trouble with the above is that it won't work when 4.0 comes out (alpha should be pretty soon). Of course an extra test could be added, but I don't think it's needed. Did you mean to 'test "$PHP_MYSQL" = "yes"' up there, instead of '!='? You could remove the else clause, and just put the AC_MSG_RESULT() outside the if. Plus, there are some bashisms there that aren't portable. I wouldn't doubt that there are some ways to make it better.. that was a quick throw-together that took me about 5 minutes to make. The reason it's "$PHP_MYSQL" != "yes" is because it's called from after it's been determined that the user wants MySQL support, and a value of "yes" is the value that is passed if the user wants to use the built-in library (or so I could tell by reading the code..). I suppose most of that could be rewritten to, perhaps something like the following: AC_DEFUN(PHP_MYSQL_VERSION,[ if test "$PHP_MYSQL" != "yes"; then AC_MSG_CHECKING(for MySQL version) if test -x "$PHP_MYSQL/bin/mysql_config"; then AC_MSG_RESULT(3.23 or better) PHP_EVAL_LIBLINE($PHP_MYSQL/bin/mysql_config --libs) else AC_MSG_RESULT(3.22 or earlier) fi fi ]) (yet another 5 minute job.. I don't see any bash-isms in there, but there could be some..) Of course, this should only be called once it's been determined that the user wants MySQL support and they don't want the built-in library.. Chris PS: This is just an example.. as I mentioned, I'm sure there are better ways to write it. -- 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]
Re: [PHP-DEV] PHP 4.0 Bug #8982: socket support not compiled
On 29 Jan 2001 [EMAIL PROTECTED] wrote: From: [EMAIL PROTECTED] Operating system: Windows 2000 PHP version: 4.0.3pl1 PHP Bug Type: Feature/Change Request Bug description: socket support not compiled Since compiling source code in Windows incorporates the use of expensive software (or knowledge of it thereof), a PHP version for Windows compiled with the --enable-sockets switch would be muchly appreciated. I would be willing to do this, but I have no knowledge of winsock. The sockets extension is only functional on unix at the moment. I wouldn't imagine that it would be difficult to port it to windows, but it hasn't been done yet (which is why you don't have it). Chris -- 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]
[PHP-DEV] PHP 4.0 Bug #9187 Updated: unable to use socket
ID: 9187 Updated by: chrisv Reported By: [EMAIL PROTECTED] Status: Open Old-Bug Type: Sockets related Bug Type: Feature/Change Request Assigned To: Comments: The sockets extension is not currently supported on Win32 (9x/ME/NT/2k). Changing to feature request. (Something to add to my to-do list: learn winsock.) Previous Comments: --- [2001-02-09 03:38:38] [EMAIL PROTECTED] when trying to create a Socket i get a undefined function error i think it has something to do with --enable-sockets and not being able to do the configure in windows i used the windows binary precompiled version of php 4.04 --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=9187edit=2 -- 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]
[PHP-DEV] PHP 4.0 Bug #9326 Updated: Warning: REG_EPAREN in query when qeuery for (au open brackets
ID: 9326
Updated by: chrisv
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Old-Bug Type: Strings related
Bug Type: Variables related
Assigned To:
Comments:
First off, you might want to try upgrading PHP. Current release is 4.0.4pl1 and 4.0.5
is in development.
As for the error, try escaping the string. '(' is a special character in regular
expressions meaning to begin a group of characters for use in a backreference.
Something to the effect of:
preg_replace("/\\(/", "\\(", $str)
though you'll want to test that before actually using it.
Previous Comments:
---
[2001-02-18 14:19:36] [EMAIL PROTECTED]
I'm using the following binary version of php4
PHP 4.0 Release Candidate 1 - Win32 Distribution
I'm using the following function for "highlighting" the query string in
a query result string
function highlightstring ($str)
{
global $Eingabewort;
//ganzer String wird "lower case" gesetzt und getauscht
$Eingabewort_lc=strtolower($Eingabewort);
$str= ereg_replace("$Eingabewort_lc", "b$Eingabewort_lc/b", $str);
//Erster Buchstabe wird Groß gesetzt und getauscht
$Eingabewort_uc=ucfirst($Eingabewort);
$str= ereg_replace("$Eingabewort_uc", "b$Eingabewort_uc/b", $str);
//ganzer String wird "upper case" gesetzt und getauscht
$Eingabestring_uc=strtoupper($Eingabewort);
$str= ereg_replace("$Eingabestring_uc", "b$Eingabestring_uc/b", $str);
return $str;
}
When I'm querying for a open bracket "(" the result is a warning:
Warning: REG_EPAREN
You can check this by simply typing into the field "insert search string"
ths string "(au" or "(fu".
The URL is
www.myjmk.com
The same error occurs with using just the bracket "(".
But I fixed this exception.
This error seems to occur ramdomly.
If I'm not using the function above the query works fine, so it must be
a problem of the "ereg_replace" function.
thanks for your help
Jan Kunberger
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9326edit=2
--
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]
Re: [PHP-DEV] PHP 4.0 Bug #8856 Updated: gethostbyname returnshostname instead of adress
For at least some months, gethostbyname() in sockets.c has been replaced by gethostbyname() in ext/standard/dns.c which does sockets.c in ext/sockets? That has been #if 0'd out ever since it was originally written in there (I wrote it, not noticing that there was already one in the standard base. Oops.) Chris -- 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]
Re: [PHP-DEV] Bi-directional popen()
On Wed, 21 Mar 2001, Anil Madhavapeddy wrote:
This has come up a few times, but is there any chance of having a
bi-directional popen() that doesn't depend on the underlying system
call supporting it?
Hm.. it would be possible to make one that uses socketpair() instead of
pipe() to do it's work.
Something to the effect of:
/* Real global */
int return_code = 0;
pid_t last_pid = 0; /* This means it can only have one popen() going at
once.. */
void php_sigchld_handler(int sig)
{
int status;
pid_t pid;
pid = wait4(-1, status, WNOHANG, NULL);
if (pid 0)
{
if (WIFEXITED(status))
{
return_code = WEXITSTATUS(status);
}
}
return;
}
int php_pclose(FILE *pipe)
{
int fd = _fileno(pipe);
int ret;
int status;
fclose(pipe);
ret = wait4(last_pid, status, WNOHANG, NULL);
if (ret == 0)
{
kill(last_pid, SIGTERM);
if (ret == 0)
return return_code;
else
return WEXITSTATUS(status);
}
else
{
return WEXITSTATUS(status);
}
}
FILE* php_popen(char *cmd, char *mode)
{
int fds[2];
FILE *ret;
pid_t pid;
int i;
if ((mode[0] == 'r' || mode[0] == 'w') mode[1] == '\0')
{
return popen(cmd, mode);
}
else
{
if (socketpair(AF_INET, SOCK_STREAM, 0, fds[2]) == 0)
{
pid = fork();
if (pid 0)
{
/* Parent process */
/* Catch SIGCHLD to tell us when it's exited. */
(void) signal(SIGCHLD, php_sigchld_handler);
/* Create a FILE* from the file descriptor */
ret = fdopen(fds[0], "w+");
if (ret == NULL)
{
/* Oh -- can't fdopen()? */
(void) kill(ret, SIGKILL);
}
/* And we're done */
return ret;
}
else if (pid == 0)
{
/* Child process */
for (i = 0; i 1024; i++) {
if (i != fds[1])
{
(void) close(i);
}
}
/* Create stdin/stdout/stderr */
dup2(fds[1], 0);
dup2(fds[1], 1);
dup2(fds[1], 2);
execl("/bin/sh", "-c", cmd, (char *) 0);
exit(127);
}
else
{
return NULL;
}
}
}
}
PS: This is just a quick hack. I think it might work as is, but it's not
something I would try using as-is without checking it out first.
Chris
--
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]
Re: [PHP-DEV] Question about socket ext. file descriptors
On Thu, 29 Mar 2001, Lars Torben Wilson wrote: Zeev Suraski writes: Note that the situation isn't as bad as you thought - it's not that it's not using the resource mechanism. It is, if it wasn't, we'd be getting loads of complaints from people running out of descriptors very quickly. It just uses old, PHP 3 style resources, of type IS_LONG. They're still destroyed when the request ends, so it's all safe and all. It simply doesn't use the PHP 4 style, of type IS_RESOURCE, which are actually destroyed when they're no longer needed. It's a good idea to update this code, but it's not very dangerous the way it is now. This doesn't look like what I remember from PHP...for instance, send() definitely isn't using any form of resources. Lars - apparently you got it wrong; The integers you are getting are *not* file descriptors. They're resource handles, of type IS_LONG. They might accidentally correspond to the file descriptors, but it'd be complete coincidence. In short, regardless of whether we upgrade the file functions to use IS_RESOURCE resources or not, what they return cannot be relied upon as file descriptor numbers, simply because they're not. I hope that clears it up... Zeev I hate to argue with you :) but this sure looks like it's passing back the descriptor (I could be missing something so if I am just shoot me): snip Nope, you aren't missing anything. The extension, I admit, is breaking some rules -- negative values instead of false for return values for example. OTOH, it *is* perfectly possible, for example, that socket() might return 0, which evaluates to false and is yet a valid file descriptor. The reason for returning file descriptors instead of resources was primarily select(). One thing I was considering doing was writing a file descriptor table (an fd_set perhaps) that keeps track of the open file descriptors, and at the end of the request (PHP_RSHUTDOWN...) closes all of the open sockets. I'm currently updating my CVS tree so I can update the current source with something to make sure that stuff opened here is closed at the end of it. For this, I'm not too fond of going the resource route for it, simply because I know people are more familiar with the C interfaces to socket() and friends (I know I'm not alone in this, but if I seem to be, feel free to speak up now).. so it makes the interfaces more familiar to people who would want to use it (and since I tried to keep the interfaces as similar as possible, it also means that people don't have to go running to the manual for everything except for the few oddities .. 'man socket' will tell you all you need to know about socket() on any decent *nix system.) I'm attempting to compile my fix for it now, will commit soon if compile goes well. Chris -- 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]
Re: [PHP-DEV] anyone working on xml-rpc extension ?
There is an XML-RPC client/server implementation (written in PHP) avaliable -- try http://xmlrpc.usefulinc.com/php.html. Chris On Sat, 31 Mar 2001, edmz wrote: If anyone is, I would love to help code or beta test it. THanks in advance -- 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] -- 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]
Re: [PHP-DEV] PHP 4.0 Bug #10589 Updated: buildconf not compatiblewith Gnu Libtool 1.4
ID: 10589 User Update by: [EMAIL PROTECTED] Status: Closed Bug Type: *Install and Config Description: buildconf not compatible with Gnu Libtool 1.4 [root@gecko /root]# cd /usr/src/php4 [root@gecko php4]# ./cvsclean; ./buildconf buildconf: checking installation... buildconf: autoconf version 2.13 (ok) buildconf: automake version 1.4 (ok) build/buildcheck.sh: test: integer expression expected before -ge buildconf: libtool version 1.4 found. You need libtool version 1.3.3 or newer installed to build PHP from CVS. make: *** [buildmk.stamp] Error 1 I see the problem when I force $lt_version to 1.4 (which appears to be what 'libtool --version' is returning) in build/buildcheck.sh. A patch to workaround this: ===CUT=== --- buildcheck.sh.bak Wed May 2 01:39:07 2001 +++ buildcheck.sh Wed May 2 01:37:41 2001 @@ -67,14 +67,27 @@ fi lt_version=`echo $lt_pversion|sed -e 's/\([a-z]*\)$/.\1/'` IFS=.; set $lt_version; IFS=' ' -if test $1 -gt 1 || test $2 -gt 3 || test $2 = 3 (test $3 = c || test $3 -ge 3) +if test $1 -gt 1 || test $2 -gt 3 || test $2 = 3 (test x$3 != x) then -echo buildconf: libtool version $lt_pversion (ok) + if test $3 = c || test $3 -ge 3 + then + echo buildconf: libtool version $lt_pversion (ok) + else + echo buildconf: libtool version $lt_pversion found. + echoYou need libtool version 1.3.3 or newer installed + echoto build PHP from CVS. + exit 1 + fi else -echo buildconf: libtool version $lt_pversion found. -echoYou need libtool version 1.3.3 or newer installed -echoto build PHP from CVS. -exit 1 + if test x$3 == x test $2 -lt 4 + then + echo buildconf: libtool version $lt_pversion found. + echoYou need libtool version 1.3.3 or newer installed + echoto build PHP from CVS. + exit 1 + else + echo buildconf: libtool version $lt_pversion (ok) + fi fi am_prefix=`which automake | sed -e 's#/[^/]*/[^/]*$##'` ===CUT=== Chris -- 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]
