Hello Josef,
I think nobody will refuse you to join efforts to make everything
better... but this patch I would not use to make this specific page
"better". You managed to break the page with this patch since you do not
escape the output of the user supplied input variable. This is a simple
"
Hello,
since yesterday I have retried to use zendplatform and it's debugger
together with zend studio. (PHP Version is 5.1.6, happened with 5.1.4 too)
We are getting a reproducable segmentation fault as follows:
Program received signal SIGSEGV, Segmentation fault.
0xb79c37db in zend_get_zval_ptr
Sounds like you are on the wrong list... Please Post your question to
[EMAIL PROTECTED] This mailing list is for the development of
PHP itself.
mike
PS: Is this code part of a .php file? In a "html environment" speak an
.html file you can't expect working.
[EMAIL PROTECTED] wrote:
> has some
Michael Wallner wrote:
> [EMAIL PROTECTED]:~/build/php-unicode-debug$ cli
> -d"error_reporting=8191" -r 'class c{function f(){}} class d extends
> c{function f($a){}}'
> Fatal error: Declaration of d::f() must be compatible with that of
> c::f() in Command line code on line 1
>
>
> I *really* thi
I guess this is associated with bug #36647 (
http://bugs.php.net/bug.php?id=36647 ) and I do not think that this
makes a lot sense for the applications outside and will break them. For
my company I decided that __get handlers really suck and I do not
encourage our developers to use it anymore.
I
done, if this is leaking or whatever... at least the
configuration parameters do not get scrambled anymore in my test
environment.
- mike
Mike Bretz wrote:
Hello,
i have discussed with rasmus in january 2005(!) a potential bug in
PHP4's merge_php_config function without finding a
Hello,
i have discussed with rasmus in january 2005(!) a potential bug in
PHP4's merge_php_config function without finding a real solution /
reason for what I have monitored.
Now, today I had experienced the same strange things as last year, using
current PHP5 implementation.
The story i
According to recent security alerts I have made a patch against 5.1 CVS
for bug 33605, which is already CLOSED but not fixed.
See attachment for patch and test file.
Somebody can review it and merge it into 5.1 / HEAD?
mike
--
mike peter bretzmetropolis ag / entwicklun
Can we add a notice into the configure script in 5.x when using these
extensions and move them into PECL for 6.0? A hint in 5.x will inform
the few people who are using the extensions that they will find them in
PECL in future. Maybe current configure options like "--with-hwapi" will
be kept an
Hello,
in 5.1.3RC3 there is still memory corruption happening when using __get and
foreach. IMHO this is a critical problem, since this leads to any kind of
program misbehaving up to sigsegv (what happened here in production systems).
As all memory corruption problems this can lead to security
Hello,
I would like to see a patch for current overloading function memory
fragmentations with segfault before release. See bug #36647.
As far as I know Dmitry is looking at it.
Thanks,
mike
Ilia Alshanetsky wrote:
PHP 5.1.3RC2 has just been released, about a week late, but better
late then
Hello,
we currently monitor segmentation faults on all of our production and
development servers running php 5.0.5 and 5.1.2 which leads to a
complete application failure. We will need a quick solution the reason
why I write this to the list instead of to bugs.php.net.
We traced down the pro
The wishlist on PHP6 has grown a lot last weeks. Here is what I have
missed so far:
switchable behaviours in php.ini file:
- enforced variable initialisation (throw E_ERROR where today E_NOTICE
is triggered)
- strict variable typing (This can be done with SetType already, but a
nicer language
In addition to the ongoing discussion I like to ask, how far you would
like to go?
If you like unicode support for functions, classes and variable names,
are you willing to do the same for all the php specific function names
and php language specific words? Will "function" and "class" or "return
Ilia Alshanetsky wrote:
IMHO we should restrict or "disabling" code to just the
include/require constructs, since that is the main cause for concern.
Ultimately shy of disabling php's ability to request remote files
there is no way to prevent an attacker from fetching remote code and
then
allow_url_fopen is a PHP_INI_SYSTEM flag, meens you can't change it with
.htaccess
- mike
Unknown W. Brackets wrote:
Why not simply disable allow_url_fopen on your server or servers?
With it set off, you get these errors:
Warning: main() [function.main]: URL file-access is disabled in the
Rasmus Lerdorf wrote:
What was the reasoning again for not having var be a synonym for public
in PHP5? It is a bit annoying that a simple PHP4 class using var throws
a notice in PHP5 when there is technically nothing wrong with it.
-Rasmus
I personally don't support "forward compatibilit
17 matches
Mail list logo
