Re: [PHP-DEV] singleton
Purushotham Komaravolu wrote:
Is there any way to create a singleton in Php4?
Yes, but this is the wrong list to ask such questions.
Anyhow:
PHP 4
?php
class Singleton {
function getInstance() {
static $instance;
if (!isset($instance)) {
echo Creating new object.\n;
$instance = new Singleton;
}
return $instance;
}
}
$a = Singleton::getInstance();
$b = Singleton::getInstance();
if ($a === $b) {
echo '$a and $b reference the same object.' . \n;
}
?
PHP 5
?php
class Singleton {
static $instance = null;
function getInstance() {
if (self::$instance == null) {
echo Creating new object.\n;
self::$instance = new Singleton;
}
return self::$instance;
}
}
$a = Singleton::getInstance();
$b = Singleton::getInstance();
if ($a === $b) {
echo '$a and $b reference the same object.' . \n;
}
?
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] exec_dir only in safe mode
On Thu, 20 Jun 2002, C. McCohy wrote:
it's going about the safe_mode_exec_dir configuration directive, which
allows php script to execute an external command, which is located in
specified directory only. This is able only in safe mode, not in normal
mode ..
What do you think, would it be nice to have this feature outside the
safe mode? I think it would be _very_ nice for some security reasons ...
OK, no answer is better than the negative one ;-)))
The patch follows ... I've tested it many times, should work fine ...
It provides the exec_dir configuration directive which allows user to
execute external commands located only in specified directory, if safe
mode is disabled. If safe mode is enabled, this directive is forgotten and
safe_mode_exec_dir will be used instead.
So if you think it is a good idea, add it ...
--
Bye .. C. McCohy
The killings will not stop until you Karel Roden
---
diff -uar php-4.2.1.orig/ext/standard/exec.c php-4.2.1/ext/standard/exec.c
--- php-4.2.1.orig/ext/standard/exec.c Thu Apr 25 16:02:51 2002
+++ php-4.2.1/ext/standard/exec.c Fri Jun 21 08:48:51 2002
-111,6 +111,50
return -1;
}
+ } else if (PG(exec_dir)) {
+ /* _NO_ safe mode with exec_dir enabled */
+
+ d = emalloc(strlen(PG(exec_dir)) + strlen(cmd) + 2);
+ c = strchr(cmd, ' ');
+ if (c) *c = '\0';
+ if (strstr(cmd, ..)) {
+ php_error(E_WARNING, No '..' components allowed in path);
+ efree(d);
+ efree(buf);
+ return -1;
+ }
+ b = strrchr(cmd, PHP_DIR_SEPARATOR);
+ strcpy(d, PG(exec_dir));
+ if (b) {
+ strcat(d, b);
+ } else {
+ sprintf(d, %s%c%s, d, PHP_DIR_SEPARATOR, cmd);
+ }
+ if (c) {
+ *c = ' ';
+ strcat(d, c);
+ }
+ tmp = php_escape_shell_cmd(d);
+ efree(d);
+ d = tmp;
+
+#if PHP_SIGCHILD
+ sig_handler = signal (SIGCHLD, SIG_DFL);
+#endif
+#ifdef PHP_WIN32
+ fp = VCWD_POPEN(d, rb);
+#else
+ fp = VCWD_POPEN(d, r);
+#endif
+ if (!fp) {
+ php_error(E_WARNING, Unable to fork [%s], d);
+ efree(d);
+ efree(buf);
+#if PHP_SIGCHILD
+ signal (SIGCHLD, sig_handler);
+#endif
+ return -1;
+ }
} else { /* not safe_mode */
#if PHP_SIGCHILD
sig_handler = signal (SIGCHLD, SIG_DFL);
-122,6 +166,7
#endif
if (!fp) {
php_error(E_WARNING, Unable to fork [%s], cmd);
+ efree(d);
efree(buf);
#if PHP_SIGCHILD
signal (SIGCHLD, sig_handler);
-129,6 +174,7
return -1;
}
}
+
buf[0] = '\0';
if (type==2) {
if (Z_TYPE_P(array) != IS_ARRAY) {
-453,13 +499,48
}
convert_to_string_ex(cmd);
+
+ if(PG(exec_dir)) {
+ char *d, *b;
+ b = strchr(Z_STRVAL_PP(cmd), ' ');
+ if (!b) {
+ b = strrchr(Z_STRVAL_PP(cmd), PHP_DIR_SEPARATOR);
+ } else {
+ char *c;
+ c = Z_STRVAL_PP(cmd);
+ while ((*b != PHP_DIR_SEPARATOR) (b != c)) {
+ b--;
+ }
+ if (b == c) {
+ b = NULL;
+ }
+ }
+
+ d = emalloc(Z_STRLEN_PP(cmd) + strlen(PG(exec_dir)) + 2);
+ if (b) {
+ strcpy(d, PG(exec_dir));
+ strcat(d, b);
+ } else {
+ sprintf(d, %s%c%s, PG(exec_dir), PHP_DIR_SEPARATOR,
+Z_STRVAL_PP(cmd));
+ }
+
#ifdef PHP_WIN32
- if ((in=VCWD_POPEN(Z_STRVAL_PP(cmd), rt))==NULL) {
+ if ((in=VCWD_POPEN(d, rt))==NULL) {
#else
- if ((in=VCWD_POPEN(Z_STRVAL_PP(cmd), r))==NULL) {
+ if ((in=VCWD_POPEN(d, r))==NULL) {
#endif
- php_error(E_WARNING, Unable to execute '%s', Z_STRVAL_PP(cmd));
- RETURN_FALSE;
+ php_error(E_WARNING, Unable to execute '%s', d);
+ RETURN_FALSE;
+ }
+ } else {
+#ifdef PHP_WIN32
+ if ((in=VCWD_POPEN(Z_STRVAL_PP(cmd), rt))==NULL) {
+#else
+ if ((in=VCWD_POPEN(Z_STRVAL_PP(cmd), r))==NULL) {
+#endif
+ php_error(E_WARNING, Unable to execute '%s',
Re: [PHP-DEV] Seeking Comments - Regarding header()
(..) ?php
Header('HTTP/1.0 301 Moved Permanently');
Header(Location: http://$uri;);
? (...)
Logfile: 127.0.0.3 - - [21/Jun/2002:09:25:27 +0200] GET / HTTP/1.1 301 38
(..) ?php
Header('HTTP/1.0 302 Moved Temporary');
Header(Location: http://$uri;);
? (...)
Logfile: 127.0.0.3 - - [21/Jun/2002:09:25:27 +0200] GET / HTTP/1.1 302 38
regards
marcus
At 03:34 21.06.2002, Chris Shiflett wrote:
A topic was brought up on PHP general that the Location header should
change the HTTP response code to 304 rather than 302. Rasmus suggested
that this person submit a patch, and that it would be considered.
I decided to look into this a bit more.
A 302 response code seems more appropriate as a default response code to
use when a user uses the Location header in some PHP code. However, even
though it is commonly used in code handling a POST request (to avoid a
reload=repost situation), the specification says that a response of 302 to
any method other than GET or HEAD must *not* automatically redirect the
user. Most browsers that I know of deliberately violate this, as I know
several open source projects that make use of the redirect behavior after
a POST.
After reviewing the other 300-level responses, it seems that the
definition and the implementations are rarely in synchronization. Thus,
what would others think of adding a way for PHP developers to specify
their own HTTP response code? I don't think this is currently possible,
though if it is, you can ignore everything I've said. :)
This could be allowed as an additional (optional) parameter of the
header() function, or it could be a separate function. Rather than try to
enforce the HTTP specification through the PHP engine itself (such as
making sure the required headers of certain response codes are included in
the response), the responsibility of generating a correct and proper
response would be the developer's.
Yes, this could have the unfortunate side-effect of poor developers
carelessly using this feature and rendering parts of their applications
useless on some browsers, but it would allow advanced developers even more
control over the HTTP response. After all, that response is what
developers are most interested in, so why not give them all the control
over it that we can?
Just an idea. I would, of course, volunteer my time to the development of
this if it sounds like a good idea.
Chris
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: cvs: php4 /ext/mbstring mbstring.c
Markus Fischer wrote: I'm +1 on removing ext/session too, it's a pretty good idea. We can do this along with ext/standard as long as the user knows what they're doing ... I guess what he meant was that there is '--disable-session' to disable the session extension. -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Seeking Comments - Regarding header()
Yes, a clean way to force the response code would be good. You can
currently do that by sending a header('HTTP/...') but a
header('location...') call overrides this and forces a 302. I think an
optional argument to the header function that forces a specific response
code would probably be the best approach. It does of course let the user
shoot himself in the foot with bogus combinations of response headers and
codes, but that can't really be helped.
-Rasmus
On Thu, 20 Jun 2002, Chris Shiflett wrote:
A topic was brought up on PHP general that the Location header should
change the HTTP response code to 304 rather than 302. Rasmus suggested
that this person submit a patch, and that it would be considered.
I decided to look into this a bit more.
A 302 response code seems more appropriate as a default response code
to use when a user uses the Location header in some PHP code. However,
even though it is commonly used in code handling a POST request (to
avoid a reload=repost situation), the specification says that a response
of 302 to any method other than GET or HEAD must *not* automatically
redirect the user. Most browsers that I know of deliberately violate
this, as I know several open source projects that make use of the
redirect behavior after a POST.
After reviewing the other 300-level responses, it seems that the
definition and the implementations are rarely in synchronization. Thus,
what would others think of adding a way for PHP developers to specify
their own HTTP response code? I don't think this is currently possible,
though if it is, you can ignore everything I've said. :)
This could be allowed as an additional (optional) parameter of the
header() function, or it could be a separate function. Rather than try
to enforce the HTTP specification through the PHP engine itself (such as
making sure the required headers of certain response codes are included
in the response), the responsibility of generating a correct and proper
response would be the developer's.
Yes, this could have the unfortunate side-effect of poor developers
carelessly using this feature and rendering parts of their applications
useless on some browsers, but it would allow advanced developers even
more control over the HTTP response. After all, that response is what
developers are most interested in, so why not give them all the control
over it that we can?
Just an idea. I would, of course, volunteer my time to the development
of this if it sounds like a good idea.
Chris
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Suggestion about native DB support.
On Fri, 21 Jun 2002, Yasuo Ohgaki wrote: Garland Foster wrote: I have a strong feeling that it would be a very good idea to ship PHP (*nix and Win) with some native, BUNDLED support for some DBM-files format. It can be very nice to have a native set of DBM-like functions available in PHP no matter the operating system or how PHP was compiled. I think gettext module is also a good one to be enabled by default or recommend users strongly. It relies on an external library, so that won't be a good thing. gettext is not available for every platform, and we are not going to bundle it. Most I18N(?) aware PHP applications are not using gettext and using slower approch, define messages as PHP vars or constants. Enabling gettext by default may change this situation in the long run. Do we need to prevent everybody from shooting in their feet? I don't think so. Users who need it will find out about gettext. Since we cannot bundle everything, how about have a logo program for a standard php installations? If users confirm standard requirements, give permission to use PHP standard logo, for example. How would this help them, and what does it give us (The PHP team)? Derick --- Did I help you? http://www.derickrethans.nl/link.php?url=giftlist Frequent ranting: http://www.derickrethans.nl/ --- PHP: Scripting the Web - [EMAIL PROTECTED] All your branches are belong to me! SRM: Script Running Machine - www.vl-srm.net --- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Seeking Comments - Regarding header()
The HTTP/1.1 spec says that anything sent as a location header must be an
absolute URI. Apache will sometimes segfault if you don't.
If a specific redirect() function were to be implemented, would it be
worth
examining the URL passed into the function to see if it is absolute (e.g.
if
it contains '://') and if it isn't, making it absolute by adding
$_SEVER['HTTP_HOST']?
What's stoping people to write userspace function using header('HTTP/1.0 xxx
...') and header('Location: ...')?
Edin
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] $HTTP_*_VARS deprecation status request
On Thu, 20 Jun 2002, Philip Olson wrote: Hello, Any idea if/when these variables won't be created by PHP? What about never? :) Derick --- Did I help you? http://www.derickrethans.nl/link.php?url=giftlist Frequent ranting: http://www.derickrethans.nl/ --- PHP: Scripting the Web - [EMAIL PROTECTED] All your branches are belong to me! SRM: Script Running Machine - www.vl-srm.net --- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: $HTTP_*_VARS deprecation status request
On Fri, 21 Jun 2002, Yasuo Ohgaki wrote: Philip Olson wrote: Hello, Any idea if/when these variables won't be created by PHP? Regards, Philip Olson $HTTP_*_VARS could waste a lot of memory when input conversion is needed. I would like to remove $HTTP_*_VARS, but I think it won't be depreciated anytime soon. PHP7? may be? We are better to have loadmap for these issues. We're not a communistic organisation where things are planned in 5 year plans. Having a road map up to PHP 7 is not really feasible, and IMO this should never be removed. Derick --- Did I help you? http://www.derickrethans.nl/link.php?url=giftlist Frequent ranting: http://www.derickrethans.nl/ --- PHP: Scripting the Web - [EMAIL PROTECTED] All your branches are belong to me! SRM: Script Running Machine - www.vl-srm.net --- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Seeking Comments - Regarding header()
Patch is done... now testing it.
Derick
On Fri, 21 Jun 2002, Rasmus Lerdorf wrote:
Yes, a clean way to force the response code would be good. You can
currently do that by sending a header('HTTP/...') but a
header('location...') call overrides this and forces a 302. I think an
optional argument to the header function that forces a specific response
code would probably be the best approach. It does of course let the user
shoot himself in the foot with bogus combinations of response headers and
codes, but that can't really be helped.
-Rasmus
On Thu, 20 Jun 2002, Chris Shiflett wrote:
A topic was brought up on PHP general that the Location header should
change the HTTP response code to 304 rather than 302. Rasmus suggested
that this person submit a patch, and that it would be considered.
I decided to look into this a bit more.
A 302 response code seems more appropriate as a default response code
to use when a user uses the Location header in some PHP code. However,
even though it is commonly used in code handling a POST request (to
avoid a reload=repost situation), the specification says that a response
of 302 to any method other than GET or HEAD must *not* automatically
redirect the user. Most browsers that I know of deliberately violate
this, as I know several open source projects that make use of the
redirect behavior after a POST.
After reviewing the other 300-level responses, it seems that the
definition and the implementations are rarely in synchronization. Thus,
what would others think of adding a way for PHP developers to specify
their own HTTP response code? I don't think this is currently possible,
though if it is, you can ignore everything I've said. :)
This could be allowed as an additional (optional) parameter of the
header() function, or it could be a separate function. Rather than try
to enforce the HTTP specification through the PHP engine itself (such as
making sure the required headers of certain response codes are included
in the response), the responsibility of generating a correct and proper
response would be the developer's.
Yes, this could have the unfortunate side-effect of poor developers
carelessly using this feature and rendering parts of their applications
useless on some browsers, but it would allow advanced developers even
more control over the HTTP response. After all, that response is what
developers are most interested in, so why not give them all the control
over it that we can?
Just an idea. I would, of course, volunteer my time to the development
of this if it sounds like a good idea.
Chris
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
---
Did I help you? http://www.derickrethans.nl/link.php?url=giftlist
Frequent ranting: http://www.derickrethans.nl/
---
PHP: Scripting the Web - [EMAIL PROTECTED]
All your branches are belong to me!
SRM: Script Running Machine - www.vl-srm.net
---
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Seeking Comments - Regarding header()
The HTTP/1.1 spec says that anything sent as a location header must be an
absolute URI. Apache will sometimes segfault if you don't.
If a specific redirect() function were to be implemented, would it be
worth
examining the URL passed into the function to see if it is absolute (e.g.
if
it contains '://') and if it isn't, making it absolute by adding
$_SEVER['HTTP_HOST']?
What's stoping people to write userspace function using header('HTTP/1.0 xxx
...') and header('Location: ...')?
The header('location') call would override the status code set in the
header('http') call. That's the whole issue here. header('location')
forces a 302 currently.
-Rasmus
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Seeking Comments - Regarding header()
On Fri, Jun 21, 2002 at 09:50:01AM +0100, Mike Hall wrote : The HTTP/1.1 spec says that anything sent as a location header must be an absolute URI. Apache will sometimes segfault if you don't. Eh ?! If it is really apache which crashes, the apache group would surely be interested to know about this, don't you think ? Do you have a sample which reproduces this crash? You could hardly describe it as a bug if Apache crashes because you're sending Headers that violate the spec, surely? -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Bug #17892: Error Handling for eval()
Hi,
I think you're idea is pretty good, however not the way you
engaged the current behaviour imho.
PHP also supports 'lint'ing of source code aka. checking for
parserer errors. It's just a few minutes work to provide the
same functionality for a new function:
$retval = lint($code);
This would also throw parserer errors right at you, if you
don't want, use '@' to supress it. It could be named
'eval_test' as someone on IRC (hey guys, btw:) suggested, or
an optional argument to eval() to do only linting of the
source, whatever.
I've attached a small patch against
Zend/zend_builtin_functions.c from CVS a few days ago (but it
can be done everywhere, e.g. ext/standard ). I didn't
commited it because a) I wasn't unsure if ppl want it and b)
if it's the proper way to do it that way (it works for me).
Any of the developers care reviewing, (fixing,) commiting ?
:)
- Markus
On Fri, Jun 21, 2002 at 08:57:43AM -, [EMAIL PROTECTED] wrote :
From: [EMAIL PROTECTED]
Operating system: Any
PHP version: 4.2.1
PHP Bug Type: Feature/Change Request
Bug description: Error Handling for eval()
I want to handle Parse_Errors and similar Fatals with my custom error
handler when they occur in eval()'d code.
This is necessary when i want to execute custom code in my console script
and prevent this code from crashing my entire program if there is only a
simple typo in there...
I have achieved this by a little hack in the zend_execute.c but i don't
know if this handles any errors right that don't occur in eval'd()
code...
This is what i changed (to even prevent a segmentation fault)
(zend_execute.c, line 1563):
if (zend_hash_find(active_function_table, function_name-value.str.val,
function_name-value.str.len+1, (void **) function)==FAILURE) {
zend_error(E_USER_ERROR, Call to undefined function: %s(),
function_name-value.str.val);
return;
}
--
Edit bug report at http://bugs.php.net/?id=17892edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=17892r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=17892r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=17892r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=17892r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=17892r=support
Expected behavior: http://bugs.php.net/fix.php?id=17892r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=17892r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=17892r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=17892r=globals
--
GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc
Did I help you?http://guru.josefine.at/wish_en
Konnte ich helfen? http://guru.josefine.at/wish_de
uhmm.. the dates in the bug db.. aren't they printed a bit wrong, i mean, did
i miss when we changed to 53 days/month ( +2002-02-53) ? =P - N0v3ll
Index: zend_builtin_functions.c
===
RCS file: /repository/Zend/zend_builtin_functions.c,v
retrieving revision 1.118
diff -u -r1.118 zend_builtin_functions.c
--- zend_builtin_functions.c12 Jun 2002 17:02:22 - 1.118
+++ zend_builtin_functions.c21 Jun 2002 09:52:25 -
@@ -68,6 +68,7 @@
#if ZEND_DEBUG
static ZEND_FUNCTION(zend_test_func);
#endif
+static ZEND_FUNCTION(lint);
ZEND_API unsigned char first_arg_force_ref[] = { 1, BYREF_FORCE };
ZEND_API unsigned char second_arg_force_ref[] = { 2, BYREF_NONE, BYREF_FORCE };
@@ -119,6 +120,7 @@
#if ZEND_DEBUG
ZEND_FE(zend_test_func, NULL)
#endif
+ ZEND_FE(lint, NULL)
{ NULL, NULL, NULL }
};
@@ -1185,3 +1187,31 @@
}
}
/* }}} */
+
+/* {{{ proto bool lint(string code)
+ Returns true of code doesn't throw any parser error, else false */
+ZEND_FUNCTION(lint)
+{
+ zval **phpcode;
+ zend_op_array *op_array;
+
+ if (ZEND_NUM_ARGS() != 1 || zend_get_parameters_ex(1, phpcode)) {
+ ZEND_WRONG_PARAM_COUNT();
+ }
+
+ convert_to_string_ex(phpcode);
+
+ zend_try {
+ op_array = compile_string(*phpcode, - TSRMLS_CC);
+
+ if (op_array) {
+ destroy_op_array(op_array);
+ efree(op_array);
+ RETURN_TRUE;
+ } else {
+ RETURN_FALSE;
+ }
+ } zend_end_try();
+
+ RETURN_FALSE;
+}
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Bug #17892: Error Handling for eval()
Markus,
The problem is that compile_string() will add functions and classes to
PHP's global structures. Also, if there's a parse error it can leave the
internal compiler structures in an unstable state.
I can't think of any quick and easy way of support this kind of lint
feature nor eval() recovery.
Andi
At 11:59 AM 6/21/2002 +0200, Markus Fischer wrote:
Hi,
I think you're idea is pretty good, however not the way you
engaged the current behaviour imho.
PHP also supports 'lint'ing of source code aka. checking for
parserer errors. It's just a few minutes work to provide the
same functionality for a new function:
$retval = lint($code);
This would also throw parserer errors right at you, if you
don't want, use '@' to supress it. It could be named
'eval_test' as someone on IRC (hey guys, btw:) suggested, or
an optional argument to eval() to do only linting of the
source, whatever.
I've attached a small patch against
Zend/zend_builtin_functions.c from CVS a few days ago (but it
can be done everywhere, e.g. ext/standard ). I didn't
commited it because a) I wasn't unsure if ppl want it and b)
if it's the proper way to do it that way (it works for me).
Any of the developers care reviewing, (fixing,) commiting ?
:)
- Markus
On Fri, Jun 21, 2002 at 08:57:43AM -, [EMAIL PROTECTED] wrote :
From: [EMAIL PROTECTED]
Operating system: Any
PHP version: 4.2.1
PHP Bug Type: Feature/Change Request
Bug description: Error Handling for eval()
I want to handle Parse_Errors and similar Fatals with my custom error
handler when they occur in eval()'d code.
This is necessary when i want to execute custom code in my console script
and prevent this code from crashing my entire program if there is only a
simple typo in there...
I have achieved this by a little hack in the zend_execute.c but i don't
know if this handles any errors right that don't occur in eval'd()
code...
This is what i changed (to even prevent a segmentation fault)
(zend_execute.c, line 1563):
if (zend_hash_find(active_function_table, function_name-value.str.val,
function_name-value.str.len+1, (void **) function)==FAILURE) {
zend_error(E_USER_ERROR, Call to undefined function: %s(),
function_name-value.str.val);
return;
}
--
Edit bug report at http://bugs.php.net/?id=17892edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=17892r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=17892r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=17892r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=17892r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=17892r=support
Expected behavior: http://bugs.php.net/fix.php?id=17892r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=17892r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=17892r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=17892r=globals
--
GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc
Did I help you?http://guru.josefine.at/wish_en
Konnte ich helfen? http://guru.josefine.at/wish_de
uhmm.. the dates in the bug db.. aren't they printed a bit wrong, i mean, did
i miss when we changed to 53 days/month ( +2002-02-53) ? =P - N0v3ll
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Bug #17892: Error Handling for eval()
Thanks for the quick answer, much what I expected :-) However, providing a function for the lexical scanner would be neat. - Markus On Fri, Jun 21, 2002 at 12:57:28PM +0300, Andi Gutmans wrote : The problem is that compile_string() will add functions and classes to PHP's global structures. Also, if there's a parse error it can leave the internal compiler structures in an unstable state. I can't think of any quick and easy way of support this kind of lint feature nor eval() recovery. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Seeking Comments - Regarding header()
On Fri, 21 Jun 2002, Mike Hall wrote: On Fri, Jun 21, 2002 at 09:50:01AM +0100, Mike Hall wrote : The HTTP/1.1 spec says that anything sent as a location header must be an absolute URI. Apache will sometimes segfault if you don't. Eh ?! If it is really apache which crashes, the apache group would surely be interested to know about this, don't you think ? Do you have a sample which reproduces this crash? You could hardly describe it as a bug if Apache crashes because you're sending Headers that violate the spec, surely? crash = bug, always Derick --- Did I help you? http://www.derickrethans.nl/link.php?url=giftlist Frequent ranting: http://www.derickrethans.nl/ --- PHP: Scripting the Web - [EMAIL PROTECTED] All your branches are belong to me! SRM: Script Running Machine - www.vl-srm.net --- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Seeking Comments - Regarding header()
On Fri, Jun 21, 2002 at 10:48:33AM +0100, Mike Hall wrote : You could hardly describe it as a bug if Apache crashes because you're sending Headers that violate the spec, surely? Hmm ... I'm not sure. I don't think apache should crash. but then how can you be sure it's apache who crashes and not php? If it's an apache crash it maybe can be missused too (though not remotely). Well, if you send relative URLs in a Location: header, it causes intermittent sig11's in Apache. Don't know if that is mod_php causing them, or apache. But it does happen. I had that problem on GG.COM .. took me weeks to track it down to relative location headers. --Mike -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php 4.2.2
Ilia A. wrote: Would it be possible to include the fixes made by Andy to the zend_constants.c, which resolves at least 2 major bugs with constants? Ilia doesn't the same problem apply to function and method names, too? PS: IMHO using a locale-independent tolower() alternative in the engine would be a better solution than what we have now ... -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de/ +49-711-99091-77 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Suggestion about native DB support.
[EMAIL PROTECTED] wrote: On Fri, 21 Jun 2002, Yasuo Ohgaki wrote: Garland Foster wrote: I have a strong feeling that it would be a very good idea to ship PHP (*nix and Win) with some native, BUNDLED support for some DBM-files format. It can be very nice to have a native set of DBM-like functions available in PHP no matter the operating system or how PHP was compiled. I think gettext module is also a good one to be enabled by default or recommend users strongly. It relies on an external library, so that won't be a good thing. gettext is not available for every platform, and we are not going to bundle it. I agree. Bundling everything is not good. Most I18N(?) aware PHP applications are not using gettext and using slower approch, define messages as PHP vars or constants. Enabling gettext by default may change this situation in the long run. Do we need to prevent everybody from shooting in their feet? I don't think so. Users who need it will find out about gettext. Right. We can explain a bit in some documents. Since we cannot bundle everything, how about have a logo program for a standard php installations? If users confirm standard requirements, give permission to use PHP standard logo, for example. How would this help them, and what does it give us (The PHP team)? Not a PHP developers (I mean people who write C source), but PHP user will have benefits from this. We cannot rely on module like gettext to write I18N web site, since most installations do not support gettext. (DBA also) If we recommend, many hosting service providers may start supporting it. I would like to see some kind of installation standard or recommendataion for script portability. That's why I cross posted this to evangelism lists. Isn't this a evangelism issue? Anyone? -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Suggestion about native DB support.
Yasuo Ohgaki wrote: I think gettext module is also a good one to be enabled by default or recommend users strongly. well, as everything depending on setlocale() or putenv(LANG=...) is *not* threadsafe this might be a not-so-good idea right now ... -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de/ +49-711-99091-77 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] What is a persistent constant (resend)
Hello, I already sent this question, but there was no answer, and i'm afraid it was not noticed, but if this is the wrong list, let me know :) When you define a constant you can use two things that are not very clear to me. Can someone explain? 1) CONST_PERSISTENT. How can a constant be persistent? The documentation says that the constant is not forgotten after the process stops. Well if the process stops, where is the constant stored? I couldn't find any place where the constant would be written to a file or some location. Then when then module is started again, all programs I have looked at register those same constants again, so what is the point of making them persistent? Something is not getting into my small brain, there. 2) REGISTER_MAIN_.. Those are supposed to remain in the symbol table. The only symbol table I see is the Zend constant symbol table. So if the process ends, then they're lost, and that's fine with me. But if a module registers a constant as MAIN, then gets unloaded, the constants stay, available for other modules I guess. So I understand REGISTER_MAIN (I think), although I don't really see the point, but i'm totally not clear about CONST_PERSISTENT. Anyone can explain? Thanks! Fab.
Re: [PHP-DEV] Re: Suggestion about native DB support.
Yasuo Ohgaki wrote: It relies on an external library, so that won't be a good thing. gettext is not available for every platform, and we are not going to bundle it. I agree. Bundling everything is not good. it's even more tricky in case of gettext, as its functions are available as a seperate library, but are also part of GNU glibc, which is the default system C library on Linux OTOH making setlocale() and gettext() work fine with ZTS without overwriting language settings for other threads might require some patching of the library functions themselve, so that might be an argument *for* bundling in this case ... -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de/ +49-711-99091-77 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Suggestion about native DB support.
Derick et al, What about the native DBM support? Nobody answered that part. - Original Message - From: [EMAIL PROTECTED] To: Yasuo Ohgaki [EMAIL PROTECTED] Cc: PHP Developers Mailing List [EMAIL PROTECTED]; Garland Foster [EMAIL PROTECTED] Sent: Friday, June 21, 2002 5:58 AM Subject: Re: [PHP-DEV] Re: Suggestion about native DB support. On Fri, 21 Jun 2002, Yasuo Ohgaki wrote: Garland Foster wrote: I have a strong feeling that it would be a very good idea to ship PHP (*nix and Win) with some native, BUNDLED support for some DBM-files format. It can be very nice to have a native set of DBM-like functions available in PHP no matter the operating system or how PHP was compiled. I think gettext module is also a good one to be enabled by default or recommend users strongly. It relies on an external library, so that won't be a good thing. gettext is not available for every platform, and we are not going to bundle it. Most I18N(?) aware PHP applications are not using gettext and using slower approch, define messages as PHP vars or constants. Enabling gettext by default may change this situation in the long run. Do we need to prevent everybody from shooting in their feet? I don't think so. Users who need it will find out about gettext. Since we cannot bundle everything, how about have a logo program for a standard php installations? If users confirm standard requirements, give permission to use PHP standard logo, for example. How would this help them, and what does it give us (The PHP team)? Derick -- - Did I help you? http://www.derickrethans.nl/link.php?url=giftlist Frequent ranting: http://www.derickrethans.nl/ -- - PHP: Scripting the Web - [EMAIL PROTECTED] All your branches are belong to me! SRM: Script Running Machine - www.vl-srm.net -- - --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.368 / Virus Database: 204 - Release Date: 6/1/02 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Suggestion about native DB support.
On Fri, Jun 21, 2002 at 10:37:15AM -0300, Garland foster wrote: What about the native DBM support? Nobody answered that part. And what about SQLite? Porting existing PHP scripts (designed for MySQL or PostgreSQL) to SQLite is easy. -- __ /*- Frank DENIS (Jedi/Sector One) [EMAIL PROTECTED] -*\ __ \ '/a href=http://www.PureFTPd.Org/; Secure FTP Server /a\' / \/ a href=http://www.Jedi.Claranet.Fr/; Misc. free software /a \/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Suggestion about native DB support.
On Fri, 21 Jun 2002, Garland foster wrote: Derick et al, What about the native DBM support? Nobody answered that part. I'm -1 on bundling anything, for the reason you will find in the archives (no need to repeat them again). Derick - Original Message - From: [EMAIL PROTECTED] To: Yasuo Ohgaki [EMAIL PROTECTED] Cc: PHP Developers Mailing List [EMAIL PROTECTED]; Garland Foster [EMAIL PROTECTED] Sent: Friday, June 21, 2002 5:58 AM Subject: Re: [PHP-DEV] Re: Suggestion about native DB support. On Fri, 21 Jun 2002, Yasuo Ohgaki wrote: Garland Foster wrote: I have a strong feeling that it would be a very good idea to ship PHP (*nix and Win) with some native, BUNDLED support for some DBM-files format. It can be very nice to have a native set of DBM-like functions available in PHP no matter the operating system or how PHP was compiled. I think gettext module is also a good one to be enabled by default or recommend users strongly. It relies on an external library, so that won't be a good thing. gettext is not available for every platform, and we are not going to bundle it. Most I18N(?) aware PHP applications are not using gettext and using slower approch, define messages as PHP vars or constants. Enabling gettext by default may change this situation in the long run. Do we need to prevent everybody from shooting in their feet? I don't think so. Users who need it will find out about gettext. Since we cannot bundle everything, how about have a logo program for a standard php installations? If users confirm standard requirements, give permission to use PHP standard logo, for example. How would this help them, and what does it give us (The PHP team)? Derick -- - Did I help you? http://www.derickrethans.nl/link.php?url=giftlist Frequent ranting: http://www.derickrethans.nl/ -- - PHP: Scripting the Web - [EMAIL PROTECTED] All your branches are belong to me! SRM: Script Running Machine - www.vl-srm.net -- - --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.368 / Virus Database: 204 - Release Date: 6/1/02 --- Did I help you? http://www.derickrethans.nl/link.php?url=giftlist Frequent ranting: http://www.derickrethans.nl/ --- PHP: Scripting the Web - [EMAIL PROTECTED] All your branches are belong to me! SRM: Script Running Machine - www.vl-srm.net --- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Suggestion about native DB support.
Well, I guess than bundling SQLite and enabling it by default is equivalent to some native always-enabled DBM support, what I want is an storage mechanism always available so applications can rely at least on that to provide examples and tests. And if they don't need anything bigger they can easily be written to use the native Database support and just that. Garland - Original Message - From: Jedi/Sector One [EMAIL PROTECTED] To: Garland foster [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; Yasuo Ohgaki [EMAIL PROTECTED]; PHP Developers Mailing List [EMAIL PROTECTED] Sent: Friday, June 21, 2002 10:42 AM Subject: Re: [PHP-DEV] Re: Suggestion about native DB support. On Fri, Jun 21, 2002 at 10:37:15AM -0300, Garland foster wrote: What about the native DBM support? Nobody answered that part. And what about SQLite? Porting existing PHP scripts (designed for MySQL or PostgreSQL) to SQLite is easy. -- __ /*- Frank DENIS (Jedi/Sector One) [EMAIL PROTECTED] -*\ __ \ '/a href=http://www.PureFTPd.Org/; Secure FTP Server /a\' / \/ a href=http://www.Jedi.Claranet.Fr/; Misc. free software /a \/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.368 / Virus Database: 204 - Release Date: 6/1/02 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Suggestion about native DB support.
On Fri, 21 Jun 2002, Yasuo Ohgaki wrote: [...] It relies on an external library, so that won't be a good thing. gettext is not available for every platform, and we are not going to bundle it. I agree. Bundling everything is not good. Bundling anything is not good :) We cannot rely on module like gettext to write I18N web site, since most installations do not support gettext. (DBA also) well, if you keep that in mind we should bundle all extensions and libraries. And i18n is simply not important for everybody. If we recommend, many hosting service providers may start supporting it. I would like to see some kind of installation standard or recommendataion for script portability. That's why I cross posted this to evangelism lists. If you want to have portablity, then all ISPs should install with as much extensions as possible... so that isn't really feasible IMO. Derick --- Did I help you? http://www.derickrethans.nl/link.php?url=giftlist Frequent ranting: http://www.derickrethans.nl/ --- PHP: Scripting the Web - [EMAIL PROTECTED] All your branches are belong to me! SRM: Script Running Machine - www.vl-srm.net --- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Suggestion about native DB support.
On Fri, 21 Jun 2002, Jedi/Sector One wrote: On Fri, Jun 21, 2002 at 10:37:15AM -0300, Garland foster wrote: What about the native DBM support? Nobody answered that part. And what about SQLite? Porting existing PHP scripts (designed for MySQL or PostgreSQL) to SQLite is easy. And what about mind, or mcrypt, or curl, or... or... There is simply too much out there. I really think that bundling more is not the way to go (maybe except for some xml thing... which I still won't like to see bundled). Derick --- PHP: Scripting the Web - [EMAIL PROTECTED] All your branches are belong to me! SRM: Script Running Machine - www.vl-srm.net --- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: Suggestion about native DB support.
If there isnt allready write a flat file storage for PEAR Lukas Smith [EMAIL PROTECTED] ___ DybNet Internet Solutions GbR Reuchlinstr. 10-11 Gebäude 4 1.OG Raum 6 (4.1.6) 10553 Berlin Germany Tel. : +49 30 83 22 50 00 Fax : +49 30 83 22 50 07 www.dybnet.de [EMAIL PROTECTED] -Original Message- From: Garland foster [mailto:[EMAIL PROTECTED]] Sent: Friday, June 21, 2002 4:02 PM To: [EMAIL PROTECTED]; Jedi/Sector One Cc: Yasuo Ohgaki; PHP Developers Mailing List Subject: Re: [PHP-DEV] Re: Suggestion about native DB support. I agree that you can't bundle everything that might be useful, I just thought that an official native form of DB support may be useful for webmasters and developers, webmasters won't need to install MySQL, Postgress, DBM and all the possible storage solutions for PHP and developers won't have to code 5 different options for an application that uses a simple key-value storage. May be the advantages outweight the bundling disadvantages... - Original Message - From: [EMAIL PROTECTED] To: Jedi/Sector One [EMAIL PROTECTED] Cc: Garland foster [EMAIL PROTECTED]; Yasuo Ohgaki [EMAIL PROTECTED]; PHP Developers Mailing List [EMAIL PROTECTED] Sent: Friday, June 21, 2002 10:58 AM Subject: Re: [PHP-DEV] Re: Suggestion about native DB support. On Fri, 21 Jun 2002, Jedi/Sector One wrote: On Fri, Jun 21, 2002 at 10:37:15AM -0300, Garland foster wrote: What about the native DBM support? Nobody answered that part. And what about SQLite? Porting existing PHP scripts (designed for MySQL or PostgreSQL) to SQLite is easy. And what about mind, or mcrypt, or curl, or... or... There is simply too much out there. I really think that bundling more is not the way to go (maybe except for some xml thing... which I still won't like to see bundled). Derick -- - PHP: Scripting the Web - [EMAIL PROTECTED] All your branches are belong to me! SRM: Script Running Machine - www.vl-srm.net -- - --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.368 / Virus Database: 204 - Release Date: 6/1/02 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: Suggestion about native DB support.
Hi Maybe Jonas' opinion about SQLlite and php is of interest in this discussion (was today on pear-dev) see http://marc.theaimsgroup.com/?l=pear-devm=102466375605972w=2 chregu From: Garland foster [mailto:[EMAIL PROTECTED]] Sent: Friday, June 21, 2002 4:02 PM To: [EMAIL PROTECTED]; Jedi/Sector One Cc: Yasuo Ohgaki; PHP Developers Mailing List Subject: Re: [PHP-DEV] Re: Suggestion about native DB support. I agree that you can't bundle everything that might be useful, I just thought that an official native form of DB support may be useful for webmasters and developers, webmasters won't need to install MySQL, Postgress, DBM and all the possible storage solutions for PHP and developers won't have to code 5 different options for an application that uses a simple key-value storage. May be the advantages outweight the bundling disadvantages... - Original Message - From: [EMAIL PROTECTED] To: Jedi/Sector One [EMAIL PROTECTED] Cc: Garland foster [EMAIL PROTECTED]; Yasuo Ohgaki [EMAIL PROTECTED]; PHP Developers Mailing List [EMAIL PROTECTED] Sent: Friday, June 21, 2002 10:58 AM Subject: Re: [PHP-DEV] Re: Suggestion about native DB support. On Fri, 21 Jun 2002, Jedi/Sector One wrote: On Fri, Jun 21, 2002 at 10:37:15AM -0300, Garland foster wrote: What about the native DBM support? Nobody answered that part. And what about SQLite? Porting existing PHP scripts (designed for MySQL or PostgreSQL) to SQLite is easy. And what about mind, or mcrypt, or curl, or... or... There is simply too much out there. I really think that bundling more is not the way to go (maybe except for some xml thing... which I still won't like to see bundled). Derick -- - PHP: Scripting the Web - [EMAIL PROTECTED] All your branches are belong to me! SRM: Script Running Machine - www.vl-srm.net -- - --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.368 / Virus Database: 204 - Release Date: 6/1/02 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- nam...christian stockeradr...bremgartnerstr. 66, ch-8003 zurich pho...+41 1 451 6021 www...http://phant.ch/chregu mob...+41 76 561 8860 [EMAIL PROTECTED] wor...+41 1 240 5670 gpg...0x5CE1DECB -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: cvs: php4 /ext/mbstring mbstring.c
My goal is NOT TO REMOVE mbstring FROM THE ext DIRECTORY. Here is what I do want: I build php for tens of thousands of web servers. Those servers are all over the world. I only want to build one default PHP core apache module that only has the standard core things and then everything else as shared extensions. This way all the servers in the US don't have to include mbstring, but the server in JP can add one line in the php.ini to load mbstring and use it. Another example is why do all of the server have to have xml/xslt in their PHP module when only a very few will be using it, this way those few can edit php.ini and load the extension. I would like to make a suggestion on extension in the ext directory. If your extension is not in the standard directory, then you should to be able to be built both statically and shared from *BOTH* the PHP ./configure line and using phpize, ./configure, make methods. I know of 2 modules that can not be built shared from the PHP ./configure line, but I do believe work with the phpize method. I will be sending another message about today about mysql, the other is sessions. I guess my sales pitch of can be removed from ext back fired. :-) Should of just stuck with can be built as a shared extension. Thanks, Brian At 1:57 PM +0100 6/21/02, Wez Furlong wrote: mailparse (now in PECL) also requires that mbstring be installed. More specifically, it requires that the mbstring headers are installed in the pear header directory when building it (mailparse) as a SCE. Also, isn't the new multibyte support in ZE dependent on mbstring in some way? (I'm just guessing here, so excuse me if I am wrong) We really need to make sure that pear/pecl installs relevant headers for SCEs when they are built, so that other SCE will work nicely too. If you do decouple mbstring, please make sure that the mbstring headers are still installed in the pear include directory too! --Wez. On 20/06/02, Brian France [EMAIL PROTECTED] wrote: Ok, what does exif need from mbstring, code wise? Taking a look at it I don't see any references to mbstring in the code. Thanks, Brian At 8:27 PM +0200 6/20/02, Marcus Börger wrote: You will break ext/exif when removing mbstrings current integration At 04:17 20.06.2002, you wrote: I am testing a patch that allows mbstring to be built as a shared extension instead of static. This would allow removing any reference to mbstring from the core PHP code and making mbstring movable out of the ext directory possible. Not that moving it out needs to happen, but as much talk about moving things out of the ext directory I thought it would be a selling point :-) The patch basically renames php_treat_data to php_treat_data_default, creates a function pointer called php_treat_data that is defaulted to php_treat_data_default, removes all mbstrings references in php_main.h and makes mbstring.c change the php_treat_data to mbstr_treat_data in the INIT function and restores its value in SHUTDOWN. Would you be interested in it? Thanks, Brian At 10:36 AM +0900 6/20/02, Yasuo Ohgaki wrote: Marcus BöRger wrote: helly Wed Jun 19 17:55:46 2002 EDT Modified files: /php4/ext/mbstring mbstring.c Log: correct handling/generating of php_mbstr_default_identify_list As I posted before, I'll try merge changes made in php4/ext/mbstring to PHP i18n project repository's source. Please note that I'm not promising that for sure. mbstring source has been modified a lot. Please check http://cvs.sourceforge.jp/cgi-bin/viewcvs.cgi/php-i18n/ to avoid duplicated work or to make sure your work is included. -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Suggestion about native DB support.
After reading Jonas analysis on SQLlite I'll have to get back to the idea of picking a DBM library and bundling it in all the php distros with a standard set of functions that all PHP developers can use from their applications. - Original Message - From: Christian Stocker [EMAIL PROTECTED] To: 'PHP Developers Mailing List' [EMAIL PROTECTED] Sent: Friday, June 21, 2002 11:08 AM Subject: RE: [PHP-DEV] Re: Suggestion about native DB support. Hi Maybe Jonas' opinion about SQLlite and php is of interest in this discussion (was today on pear-dev) see http://marc.theaimsgroup.com/?l=pear-devm=102466375605972w=2 chregu From: Garland foster [mailto:[EMAIL PROTECTED]] Sent: Friday, June 21, 2002 4:02 PM To: [EMAIL PROTECTED]; Jedi/Sector One Cc: Yasuo Ohgaki; PHP Developers Mailing List Subject: Re: [PHP-DEV] Re: Suggestion about native DB support. I agree that you can't bundle everything that might be useful, I just thought that an official native form of DB support may be useful for webmasters and developers, webmasters won't need to install MySQL, Postgress, DBM and all the possible storage solutions for PHP and developers won't have to code 5 different options for an application that uses a simple key-value storage. May be the advantages outweight the bundling disadvantages... - Original Message - From: [EMAIL PROTECTED] To: Jedi/Sector One [EMAIL PROTECTED] Cc: Garland foster [EMAIL PROTECTED]; Yasuo Ohgaki [EMAIL PROTECTED]; PHP Developers Mailing List [EMAIL PROTECTED] Sent: Friday, June 21, 2002 10:58 AM Subject: Re: [PHP-DEV] Re: Suggestion about native DB support. On Fri, 21 Jun 2002, Jedi/Sector One wrote: On Fri, Jun 21, 2002 at 10:37:15AM -0300, Garland foster wrote: What about the native DBM support? Nobody answered that part. And what about SQLite? Porting existing PHP scripts (designed for MySQL or PostgreSQL) to SQLite is easy. And what about mind, or mcrypt, or curl, or... or... There is simply too much out there. I really think that bundling more is not the way to go (maybe except for some xml thing... which I still won't like to see bundled). Derick -- - PHP: Scripting the Web - [EMAIL PROTECTED] All your branches are belong to me! SRM: Script Running Machine - www.vl-srm.net -- - --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.368 / Virus Database: 204 - Release Date: 6/1/02 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- nam...christian stockeradr...bremgartnerstr. 66, ch-8003 zurich pho...+41 1 451 6021 www...http://phant.ch/chregu mob...+41 76 561 8860 [EMAIL PROTECTED] wor...+41 1 240 5670 gpg...0x5CE1DECB -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.368 / Virus Database: 204 - Release Date: 6/1/02 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP, Java integration failed: Red Hat 7.1, JDK 1.4,Apache 1.3x
William -- I've also spend a considerable amount of time trying to get this to work on Redhat 7.2 (and maybe 7.1). I did a lot of coaxing and reconfigurations. Best I can say, it doesn't work with JDK 1.4. Once I tried 1.3.x, everything went fine. My guess is that something changed in the upgrade, but I don't have time to figure out what. -adam On Thu, 20 Jun 2002, William John Burns wrote: All: None of the many online user posts in setting up Java connectivity from within PHP have worked. RPM or tarball. Do you know of anyone who has an RPM of PHP, with the standard MySQL, GD, Postgres, WDDX, etc...but also libphp_java.so correctly set-up? The Windows PHP has Java support right off the bat with an edit the the .ini file. On Win 98, no problems at all. But on my Linux paritions... There are at least dozens of people trying to get this to work. All of them could be helped with an RPM or a definitive answer. Why can't someone release linux binaries with this sort of thing compiled in? My system: Sun Java2 JDK 1.4.0, Red Hat 7.1, Apache 1.3x. I have tried all versions of PHP tarballs since 4.04p1 And I'm not alone in this frustration. Yes, sometimes there is a libphp_java. There is always the .jar file. But after editing the .ini, doing all manner of things with LD_LIBRARY_PATH/ldconfig, nothing! The best I ever got was a page that registered the .so module, but never finished output. (I use a test page with phpinfo(), then and a sample call to get a Java timestamp. In this circumstance, the page cuts off before the sample Java timestamp and instance. Any help or leads would be appreciated. Regards, WJ Burns -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Rounding....
Matthew Clark wrote:
Seeing as the mathematically correct way to round numbers is to round down
to n for n-1=m=n.5 and up to n+1 for n.5mn+1, I wonder why the PHP
round() function couldn't include a little 'fuzz' to handle the rounding
problems we encounter due to floating point representation in the hardware?
It could even be a configurable option - but it would save writing a
wrapper...
Matthew,
I can't agree with you more.
I really don't understand the point of php having a round function which
gives the wrong answer on even very simple decimals
e.g. round(0.35,1) returns 0.3.
The fuzz you suggest works fine and need only be very small.
pow(10.0,places-DBL_DIG) seems to do the job. e.g. a change
to the source of math.c:PHP_FUNCTION(round) as follows, (changes
underlined):
f = pow(10.0, (double) places);
return_val *= f;
if (return_val = 0.0)
return_val = floor(pow(10.0,places - DBL_DIG)) + 0.5 + return_val);
-
else
return_val = ceil(return_val - (0.5 + pow(10.0,places - DBL_DIG)));
return_val /= f;
You'll note that this implies a bias to high absolute values, but then we
already
have that bias since we're rounding up anyway. The only numbers which
would be incorrectly rounded because of the bias in the fix, already have more
than 14 significant figures e.g 0.349 rounds to 0.4 but
0.34 still rounds to 0.3.
I can't see any possible reason for this not being fixed, but then I
also think we should fix the rest of the binary representation problems i.e.
1. Comparison of Floating Points
0.8 == 0.7 + 0.1; evaluates as false not true.
In general, all the comparison operators, ==, !=, =, , , =, === may
give incorrect results if either of the operands is a floating point.
2. Conversion of Floating Point to Integer
floor(10 * (0.7 + 0.1)); evaluates to 7 not 8.
In general, floor(), ceil() and (int) may give incorrect results.
3. Spurious Differences
print (0.8 - (0.7 + 0.1)); outputs 1.1102230246252E-16 not 0
4. Cumulative Conversion Errors
for($i=1,$i=10,++$i){$total = $total + 0.1;}; calculates $total
as 1. not 1
They all have the same cause as the round problem i.e. the use of binary
floating points for decimal arithmetic without any compensation for
conversion errors.
As it happens, there's a simple fix for all of these as well The fix is to
automatically
round the results of php's arithmetic operators to 15 significant figures when
floating point numbers are involved. It comes to about 20 lines of code
change
to zend_operators.c i.e.8 calls to the following new function:
double decimalise(double dval)
{
double f;
if (dval == 0)
{
return dval;
}
f = pow(10.0, DBL_DIG - (1 + floor(log10(fabs(dval);
return (double) (rint(dval*f))/f;
}
There is a performance downside, although much less than doing your own
workarounds. To put it in perspective, the impact is a twentieth of that of
using
a string cast/sprintf. Indeed, the slowdown is less than using objects or
arrays in your
arithmetic i.e. with the fix $a = $b + $c takes the same or less time than
unfixed $a = $b + $c-d
Or, to put it another way, if you are not worried about the performance impact
of using
objects and arrays in arithmetic operations, you should not be worried by the
impact of
this fix for decimal arithmetic. (The decimalise function could also be
speeded up with a
more clever calculation of f, e.g. by skipping the log10 and pow functions
but I'd rather
leave that to a real C programmer ;))
I haven't had a very enthusiastic response from the php developers in the past
on these
issues, but I'm keen to have another go if you or anyone else thinks it's
worth sorting
this out properly. Personally, I just don't see the point of having
operators/functions
in php that can go wrong at even a single decimal digit!
Regards,
George
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Rounding....Message repeated
Repeat of previous message in thread without the extra ugly wrapping, (sorry!!!)
Matthew Clark wrote:
Seeing as the mathematically correct way to round numbers is to round down
to n for n-1=m=n.5 and up to n+1 for n.5mn+1, I wonder why the PHP
round() function couldn't include a little 'fuzz' to handle the rounding
problems we encounter due to floating point representation in the hardware?
It could even be a configurable option - but it would save writing a
wrapper...
Matthew,
I can't agree with you more.
I really don't understand the point of php having a round function which
gives the wrong answer on even very simple decimals
e.g. round(0.35,1) returns 0.3.
The fuzz you suggest works fine and need only be very small.
pow(10.0,places-DBL_DIG) seems to do the job. e.g. a change
to the source of math.c:PHP_FUNCTION(round) as follows, (changes
underlined):
f = pow(10.0, (double) places);
return_val *= f;
if (return_val = 0.0)
return_val = floor(pow(10.0,places - DBL_DIG)) + 0.5 + return_val);
-
else
return_val = ceil(return_val - (0.5 + pow(10.0,places - DBL_DIG)));
return_val /= f;
You'll note that this implies a bias to high absolute values, but then we already
have that bias since we're rounding up anyway. The only numbers which
would be incorrectly rounded because of the bias in the fix, already have more
than 14 significant figures e.g 0.349 rounds to 0.4 but
0.34 still rounds to 0.3.
I can't see any possible reason for this not being fixed, but then I
also think we should fix the rest of the binary representation problems i.e.
1. Comparison of Floating Points
0.8 == 0.7 + 0.1; evaluates as false not true.
In general, all the comparison operators, ==, !=, =, , , =, === may
give incorrect results if either of the operands is a floating point.
2. Conversion of Floating Point to Integer
floor(10 * (0.7 + 0.1)); evaluates to 7 not 8.
In general, floor(), ceil() and (int) may give incorrect results.
3. Spurious Differences
print (0.8 - (0.7 + 0.1)); outputs 1.1102230246252E-16 not 0
4. Cumulative Conversion Errors
for($i=1,$i=10,++$i){$total = $total + 0.1;}; calculates $total
as 1. not 1
They all have the same cause as the round problem i.e. the use of binary
floating points for decimal arithmetic without any compensation for
conversion errors.
As it happens, there's a simple fix for all of these as well The fix is to
automatically
round the results of php's arithmetic operators to 15 significant figures when
floating point numbers are involved. It comes to about 20 lines of code change
to zend_operators.c i.e.8 calls to the following new function:
double decimalise(double dval)
{
double f;
if (dval == 0)
{
return dval;
}
f = pow(10.0, DBL_DIG - (1 + floor(log10(fabs(dval);
return (double) (rint(dval*f))/f;
}
There is a performance downside, although much less than doing your own
workarounds. To put it in perspective, the impact is a twentieth of that of using
a string cast/sprintf. Indeed, the slowdown is less than using objects or arrays in
your
arithmetic i.e. with the fix $a = $b + $c takes the same or less time than
unfixed $a = $b + $c-d
Or, to put it another way, if you are not worried about the performance impact of using
objects and arrays in arithmetic operations, you should not be worried by the impact of
this fix for decimal arithmetic. (The decimalise function could also be speeded up
with a
more clever calculation of f, e.g. by skipping the log10 and pow functions but I'd
rather
leave that to a real C programmer ;))
I haven't had a very enthusiastic response from the php developers in the past on these
issues, but I'm keen to have another go if anyone else shares my view that it's time to
sort out decimal arithmetic properly. I just don't see the point of these
operators/functions
that can go wrong at even a single decimal digit!
Regards,
George
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] overload extension doesn't load on PHP + win2k
everything is in the subject :) the error message on apache startup is: Invalid library (maybe not a PHP library) 'php_overload.dll' anyone had this problem ? here is my phpinfo: PHP Version 4.2.1 System Windows NT 5.0 build 2195 Build Date May 12 2002 23:51:56 Server API Apache Virtual Directory Support enabled Configuration File (php.ini) Path C:\WINNT\php.ini Debug Build no Thread Safety enabled __ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP... http://www.ifrance.com/_reloc/email.emailif -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: cvs: php4 /ext/mbstring mbstring.c
At 16:30 21.06.2002, Brian France wrote: My goal is NOT TO REMOVE mbstring FROM THE ext DIRECTORY. Here is what I do want: Think we understood that from your first mail! What i wanted to stree out is that exif uses functions from mbstring if present. That means if mbstring is not present it does not use these and the user has to do that stuff for his own. If mbstring is compiled as a shared extension both exif and mbstring will work together perfectly but exif cannot use mbstring even though it is present and that might/WILL be confusing to users. Hope this clears my first mail marcus I build php for tens of thousands of web servers. Those servers are all over the world. I only want to build one default PHP core apache module that only has the standard core things and then everything else as shared extensions. This way all the servers in the US don't have to include mbstring, but the server in JP can add one line in the php.ini to load mbstring and use it. Another example is why do all of the server have to have xml/xslt in their PHP module when only a very few will be using it, this way those few can edit php.ini and load the extension. I would like to make a suggestion on extension in the ext directory. If your extension is not in the standard directory, then you should to be able to be built both statically and shared from *BOTH* the PHP ./configure line and using phpize, ./configure, make methods. I know of 2 modules that can not be built shared from the PHP ./configure line, but I do believe work with the phpize method. I will be sending another message about today about mysql, the other is sessions. I guess my sales pitch of can be removed from ext back fired. :-) Should of just stuck with can be built as a shared extension. Thanks, Brian At 1:57 PM +0100 6/21/02, Wez Furlong wrote: mailparse (now in PECL) also requires that mbstring be installed. More specifically, it requires that the mbstring headers are installed in the pear header directory when building it (mailparse) as a SCE. Also, isn't the new multibyte support in ZE dependent on mbstring in some way? (I'm just guessing here, so excuse me if I am wrong) We really need to make sure that pear/pecl installs relevant headers for SCEs when they are built, so that other SCE will work nicely too. If you do decouple mbstring, please make sure that the mbstring headers are still installed in the pear include directory too! --Wez. On 20/06/02, Brian France [EMAIL PROTECTED] wrote: Ok, what does exif need from mbstring, code wise? Taking a look at it I don't see any references to mbstring in the code. Thanks, Brian At 8:27 PM +0200 6/20/02, Marcus Börger wrote: You will break ext/exif when removing mbstrings current integration At 04:17 20.06.2002, you wrote: I am testing a patch that allows mbstring to be built as a shared extension instead of static. This would allow removing any reference to mbstring from the core PHP code and making mbstring movable out of the ext directory possible. Not that moving it out needs to happen, but as much talk about moving things out of the ext directory I thought it would be a selling point :-) The patch basically renames php_treat_data to php_treat_data_default, creates a function pointer called php_treat_data that is defaulted to php_treat_data_default, removes all mbstrings references in php_main.h and makes mbstring.c change the php_treat_data to mbstr_treat_data in the INIT function and restores its value in SHUTDOWN. Would you be interested in it? Thanks, Brian At 10:36 AM +0900 6/20/02, Yasuo Ohgaki wrote: Marcus BöRger wrote: helly Wed Jun 19 17:55:46 2002 EDT Modified files: /php4/ext/mbstring mbstring.c Log: correct handling/generating of php_mbstr_default_identify_list As I posted before, I'll try merge changes made in php4/ext/mbstring to PHP i18n project repository's source. Please note that I'm not promising that for sure. mbstring source has been modified a lot. Please check http://cvs.sourceforge.jp/cgi-bin/viewcvs.cgi/php-i18n/ to avoid duplicated work or to make sure your work is included. -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: cvs: php4 /ext/mbstring mbstring.c
On 21/06/02, Brian France [EMAIL PROTECTED] wrote: My goal is NOT TO REMOVE mbstring FROM THE ext DIRECTORY. Here is what I do want: I understood that. I guess my sales pitch of can be removed from ext back fired. :-) Should of just stuck with can be built as a shared extension. What I said is still valid: If you do decouple mbstring, please make sure that the mbstring headers are still installed in the pear include directory too! If mbstring is built as a shared extension, you need to ensure that it's headers are also installed in the pear header directory, otherwise configuring other modules that depend upon it will fail. --Wez. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: cvs: php4 /ext/mbstring mbstring.c
On Fri, Jun 21, 2002 at 07:23:19PM +0200, Marcus Börger wrote : If mbstring is compiled as a shared extension both exif and mbstring will work together perfectly but exif cannot use mbstring even though it is present and that might/WILL be confusing to users. How feasible is it to implement a way to find the right mb_* function during runtime when mbstring is only available as shared module, simple said something like dlsym(foo, php_mb_check_encoding_list); (or whatever it takes for the various platforms) ? - Markus -- GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc uhmm.. the dates in the bug db.. aren't they printed a bit wrong, i mean, did i miss when we changed to 53 days/month ( +2002-02-53) ? =P - N0v3ll -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: cvs: php4 /ext/mbstring mbstring.c
At 6:57 PM +0100 6/21/02, Wez Furlong wrote: If you do decouple mbstring, please make sure that the mbstring headers are still installed in the pear include directory too! If mbstring is built as a shared extension, you need to ensure that it's headers are also installed in the pear header directory, otherwise configuring other modules that depend upon it will fail. Not a problem, all headers are install by our packaging system even if the extension is not compiled into our core PHP package. Brian -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: cvs: php4 /ext/mbstring mbstring.c
At 7:23 PM +0200 6/21/02, Marcus Börger wrote: What i wanted to stree out is that exif uses functions from mbstring if present. That means if mbstring is not present it does not use these and the user has to do that stuff for his own. If mbstring is compiled as a shared extension both exif and mbstring will work together perfectly but exif cannot use mbstring even though it is present and that might/WILL be confusing to users. That make sense, is there a change that can be made in exif to fix this problem? Looking over the code for exif again I still don't see it calling anything from mbstring and it doesn't call php_treat_data which was what mbstring was overwriting. Cheers, Brian -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] overload extension doesn't load on PHP 4.2.1 + win2k
I've just tried ... but unfortunately, I got exactly the same problem ! -Original Message- From: Markus Fischer [mailto:[EMAIL PROTECTED]] Sent: vendredi 21 juin 2002 18:24 To: phpsurf Subject: Re: [PHP-DEV] overload extension doesn't load on PHP + win2k Have you tried the latest stable and non-stable snapshots from http://snaps.php.net/win32/ ? - Markus __ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP... http://www.ifrance.com/_reloc/email.emailif -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: cvs: php4 /ext/mbstring mbstring.c
At 20:29 21.06.2002, Brian France wrote: At 7:23 PM +0200 6/21/02, Marcus Börger wrote: What i wanted to stree out is that exif uses functions from mbstring if present. That means if mbstring is not present it does not use these and the user has to do that stuff for his own. If mbstring is compiled as a shared extension both exif and mbstring will work together perfectly but exif cannot use mbstring even though it is present and that might/WILL be confusing to users. That make sense, is there a change that can be made in exif to fix this problem? Looking over the code for exif again I still don't see it calling anything from mbstring and it doesn't call php_treat_data which was what mbstring was overwriting. Cheers, Brian It uses c functions php_mb_convert_encoding and php_mb_check_encoding_list. If you do not find those in ext/exif/exif.c you are not using head since this was added right after releasing PHP 4.2. In there you'll find some #ifdef HAVE_MBSTRING lines. I think if you use PHP 4.2.x for now we will find a solution like Markus (with k) mentioned and load the needed two functions dynamically. Question to Markus: We do not allways have dlsym, have we? *nix and cygwin have dlfcn.h but my Win does not have it. So i guess the correct macros are # define DL_LOAD(libname) LoadLibrary(libname) # define DL_FETCH_SYMBOLGetProcAddress # define DL_UNLOAD FreeLibrary That would mean loading the symbols in MINIT, correct? regards marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Bug #17912 Updated: getting info from gd.so
This reminds me: don't we want to remove those code elements:
#ifdef HAVE_WHATEVER_GD_FEATURE
doit
#else
php_error(E_WARNIGN, not supported in this buil
#endif
so finally function_exists makes sense here. I'ld like to
see this happening before 4.3
reasonable or not? Maybe I miss something ...
- Markus
On Fri, Jun 21, 2002 at 07:57:41PM -, [EMAIL PROTECTED] wrote :
ID: 17912
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Bogus
Bug Type: GD related
Operating System: linux debian/mandrake
PHP Version: 4.2.1
New Comment:
phpinfo() does show the GD version. Between versions 1.6 and 1.8 there
was no way to distinguish, so it is approximate, but other versions
should be shown just fine. As for figuring out which image types are
available, use imagetypes()
Previous Comments:
[2002-06-21 15:54:39] [EMAIL PROTECTED]
im having trouble determinating to which version of GD gd.so was linked
to, phpinfo() only shows the acctual version of gd.so, but not the
version of GD it was linked to..
some variable to show the acctual gd version (major and minor) would be
nice, so i and other people would know how to dynamically use image*
functions according to that variable, because setting up each server
with platform-dependant code is a bit time consuming, and coding two
different image libraries or graphing libraries which use GD is also a
waste of time, if just a few functions change their names and
behaviour.
example would be..
if ($GD_VERSION=='1') {
imagecopyresized(...);
} else {
imagecopyresampled(...);
}
be a sweetheart and add that :* (otherwise excelent work)
--
Edit this bug report at http://bugs.php.net/?id=17912edit=1
--
GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc
Did I help you?http://guru.josefine.at/wish_en
Konnte ich helfen? http://guru.josefine.at/wish_de
uhmm.. the dates in the bug db.. aren't they printed a bit wrong, i mean, did
i miss when we changed to 53 days/month ( +2002-02-53) ? =P - N0v3ll
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: changing max size to upload
Anil Garg [EMAIL PROTECTED] wrote in message 025d01c21876$40e08a20$[EMAIL PROTECTED]">news:025d01c21876$40e08a20$[EMAIL PROTECTED]... hi, sory to post this here. How can i change the maximum size of the file being uploaded?? The line below does not seem to help me: input type=hidden name=MAX_FILE_SIZE value=25000 Do i need to make some more changes?? php ver i am using is mod_php4-4.1.2 I dont have a php.ini file anywhere!! i just have a file php.ini-dist in /usr/local/etc/ ...but i dont think it is being used. One way is to enter values in httpd.conf php_admin_value post_max_size 3000 php_value upload_max_filesize 3000 / morten -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: cvs: php4 /ext/mbstring mbstring.c
At 9:56 PM +0200 6/21/02, Marcus Börger wrote: At 20:29 21.06.2002, Brian France wrote: At 7:23 PM +0200 6/21/02, Marcus Börger wrote: What i wanted to stree out is that exif uses functions from mbstring if present. That means if mbstring is not present it does not use these and the user has to do that stuff for his own. If mbstring is compiled as a shared extension both exif and mbstring will work together perfectly but exif cannot use mbstring even though it is present and that might/WILL be confusing to users. That make sense, is there a change that can be made in exif to fix this problem? Looking over the code for exif again I still don't see it calling anything from mbstring and it doesn't call php_treat_data which was what mbstring was overwriting. It uses c functions php_mb_convert_encoding and php_mb_check_encoding_list. If you do not find those in ext/exif/exif.c you are not using head since this was added right after releasing PHP 4.2. In there you'll find some #ifdef HAVE_MBSTRING lines. Ah, it all because clear, yes I am using the 4.2.1 for all of our packages (plus our own patch fixes) so I don't see any of the those changes. I think if you use PHP 4.2.x for now we will find a solution like Markus (with k) mentioned and load the needed two functions dynamically. Great, our goal is to use the PHP source as is and not making large changes to it which would force us to stick with one version or merger patches to the next version which becomes a nightmare (lessons learned from hacking apache source). Thanks! Brian -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Bug #17912 Updated: getting info from gd.so
Hi, On Fri, Jun 21, 2002 at 08:32:18PM -, [EMAIL PROTECTED] wrote : p.s. i tried to solve this problem with function_exists(imagecreatetruecolor) but that always returns true, and after i call it it says i need GD2.0 or higher (which is the truth) That's exactly my point too. I brought this up in the past, maybe this can be fixed before 4.3 get's out. I've already contacted Rasmus, let's see what he thinks about this. - Markus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Bug #17912 Updated: getting info from gd.so
Hey,
I thought I fixed this already
Derick
On Fri, 21 Jun 2002, Markus Fischer wrote:
This reminds me: don't we want to remove those code elements:
#ifdef HAVE_WHATEVER_GD_FEATURE
doit
#else
php_error(E_WARNIGN, not supported in this buil
#endif
so finally function_exists makes sense here. I'ld like to
see this happening before 4.3
reasonable or not? Maybe I miss something ...
- Markus
On Fri, Jun 21, 2002 at 07:57:41PM -, [EMAIL PROTECTED] wrote :
ID: 17912
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Bogus
Bug Type: GD related
Operating System: linux debian/mandrake
PHP Version: 4.2.1
New Comment:
phpinfo() does show the GD version. Between versions 1.6 and 1.8 there
was no way to distinguish, so it is approximate, but other versions
should be shown just fine. As for figuring out which image types are
available, use imagetypes()
Previous Comments:
[2002-06-21 15:54:39] [EMAIL PROTECTED]
im having trouble determinating to which version of GD gd.so was linked
to, phpinfo() only shows the acctual version of gd.so, but not the
version of GD it was linked to..
some variable to show the acctual gd version (major and minor) would be
nice, so i and other people would know how to dynamically use image*
functions according to that variable, because setting up each server
with platform-dependant code is a bit time consuming, and coding two
different image libraries or graphing libraries which use GD is also a
waste of time, if just a few functions change their names and
behaviour.
example would be..
if ($GD_VERSION=='1') {
imagecopyresized(...);
} else {
imagecopyresampled(...);
}
be a sweetheart and add that :* (otherwise excelent work)
--
Edit this bug report at http://bugs.php.net/?id=17912edit=1
--
GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc
Did I help you?http://guru.josefine.at/wish_en
Konnte ich helfen? http://guru.josefine.at/wish_de
uhmm.. the dates in the bug db.. aren't they printed a bit wrong, i mean, did
i miss when we changed to 53 days/month ( +2002-02-53) ? =P - N0v3ll
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
---
Did I help you? http://www.derickrethans.nl/link.php?url=giftlist
Frequent ranting: http://www.derickrethans.nl/
---
PHP: Scripting the Web - [EMAIL PROTECTED]
All your branches are belong to me!
SRM: Script Running Machine - www.vl-srm.net
---
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Bug #17912 Updated: getting info from gd.so
On Sat, 22 Jun 2002 [EMAIL PROTECTED] wrote:
Hey,
I thought I fixed this already
Ah... but not for the 2.0 things. I'll have a look tomorrow and fix it.
Derick
Derick
On Fri, 21 Jun 2002, Markus Fischer wrote:
This reminds me: don't we want to remove those code elements:
#ifdef HAVE_WHATEVER_GD_FEATURE
doit
#else
php_error(E_WARNIGN, not supported in this buil
#endif
so finally function_exists makes sense here. I'ld like to
see this happening before 4.3
reasonable or not? Maybe I miss something ...
- Markus
On Fri, Jun 21, 2002 at 07:57:41PM -, [EMAIL PROTECTED] wrote :
ID: 17912
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Bogus
Bug Type: GD related
Operating System: linux debian/mandrake
PHP Version: 4.2.1
New Comment:
phpinfo() does show the GD version. Between versions 1.6 and 1.8 there
was no way to distinguish, so it is approximate, but other versions
should be shown just fine. As for figuring out which image types are
available, use imagetypes()
Previous Comments:
[2002-06-21 15:54:39] [EMAIL PROTECTED]
im having trouble determinating to which version of GD gd.so was linked
to, phpinfo() only shows the acctual version of gd.so, but not the
version of GD it was linked to..
some variable to show the acctual gd version (major and minor) would be
nice, so i and other people would know how to dynamically use image*
functions according to that variable, because setting up each server
with platform-dependant code is a bit time consuming, and coding two
different image libraries or graphing libraries which use GD is also a
waste of time, if just a few functions change their names and
behaviour.
example would be..
if ($GD_VERSION=='1') {
imagecopyresized(...);
} else {
imagecopyresampled(...);
}
be a sweetheart and add that :* (otherwise excelent work)
--
Edit this bug report at http://bugs.php.net/?id=17912edit=1
--
GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc
Did I help you?http://guru.josefine.at/wish_en
Konnte ich helfen? http://guru.josefine.at/wish_de
uhmm.. the dates in the bug db.. aren't they printed a bit wrong, i mean, did
i miss when we changed to 53 days/month ( +2002-02-53) ? =P - N0v3ll
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
---
Did I help you? http://www.derickrethans.nl/link.php?url=giftlist
Frequent ranting: http://www.derickrethans.nl/
---
PHP: Scripting the Web - [EMAIL PROTECTED]
All your branches are belong to me!
SRM: Script Running Machine - www.vl-srm.net
---
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
---
Did I help you? http://www.derickrethans.nl/link.php?url=giftlist
Frequent ranting: http://www.derickrethans.nl/
---
PHP: Scripting the Web - [EMAIL PROTECTED]
All your branches are belong to me!
SRM: Script Running Machine - www.vl-srm.net
---
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Bug #17912 Updated: getting info from gd.so
On Sat, Jun 22, 2002 at 12:42:51AM +0200, [EMAIL PROTECTED] wrote : On Sat, 22 Jun 2002 [EMAIL PROTECTED] wrote: Hey, I thought I fixed this already Ah... but not for the 2.0 things. I'll have a look tomorrow and fix it. That's kewl, definitely! - Markus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Suggestion about native DB support.
[EMAIL PROTECTED] wrote: If we recommend, many hosting service providers may start supporting it. I would like to see some kind of installation standard or recommendataion for script portability. That's why I cross posted this to evangelism lists. If you want to have portablity, then all ISPs should install with as much extensions as possible... so that isn't really feasible IMO. There are many successful standard programs. If we have standard/recommendation/whatever for a certain PHP configuration, many ISP may follow that. There is nothing wrong to recommend certain configuration. It will benefits us to promote more PHP usage and make advanced script avairable for sure. It makes easier to write requiement for PHP application. For example, Java users can write You need J2SE to use this application. Any opinion from evangelists? -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Suggestion about native DB support.
Hartmut Holzgraefe wrote: Yasuo Ohgaki wrote: I think gettext module is also a good one to be enabled by default or recommend users strongly. well, as everything depending on setlocale() or putenv(LANG=...) is *not* threadsafe this might be a not-so-good idea right now ... Note in the manual page says setlocale() is not required, so I was supposing it's not needed. Anyway, it seems it's been modified recently and I haven't use gettext for long time. Need some research. -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
