From: [EMAIL PROTECTED]
Operating system: Linux 2.2.19
PHP version: 4.0.6
PHP Bug Type: Compile Failure
Bug description: ./configure suxx
./configure [...] --with-zlib [...] does not work. i have zlib 1.1.3
installed in /usr/local/zlib but it always says zlib =1.0.9
From: [EMAIL PROTECTED]
Operating system: pws98
PHP version: 4.0.6
PHP Bug Type: PWS related
Bug description: php4isapi.dll path
win98/pws4/php4.0.6, using php4isapi.dll.
The oringinal path for php4isapi was h:\php. I change the path to e:\php
by using RegEdit. But
Please hold your commits until further notice. A pretty huge mega patch is
coming, and since it touches pretty much all of PHP, I need a 'relaxed'
repository...
Thanks
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands,
From: [EMAIL PROTECTED]
Operating system:
PHP version: 4.0.6
PHP Bug Type: Feature/Change Request
Bug description: Function to encode strings for XML
Currently I use
function xml_encode($xml) {
$xml = str_replace(array('ü', 'Ü', 'ö',
'Ö',
I wrote a thorough response while being disconnected, but it's kind of
pointless to send it considering the face to face discussion we had
today. The only thing I'd like say here is that in my opinion, the fact
form variables are defined as globals (as opposed to being defined just as
At 12:36 27/07/2001, Brian Tanner wrote:
Differently - sometimes
Dangerously - Never
I think that this means that this is quite serious, and mind-bogglingly
common security flaw. When your app behaves differently, there's a one out
of two, or one out of five, or one out of ten chance that
Yes, a $_FORM variable container is also on my TODO list for the new
track_vars implementation...
At 14:00 27/07/2001, Brian Tanner wrote:
Brian Foddy actually brings up a really important issue, which would go
along way to making (at least me) much happier with the proposed change.
*If* there
On Sat, 28 Jul 2001, Zeev Suraski wrote:
Anyway, to be more constructive - Andi had an idea when we were catching a
cab earlier today (yesterday). His idea (which I'm just pitching, we
haven't thought this through at all yet) is that instead of having
register_globals on, or off, we would
At 05:08 27/07/2001, [EMAIL PROTECTED] wrote:
Addressed to: Rasmus Lerdorf [EMAIL PROTECTED]
[EMAIL PROTECTED]
Or you can simply stop these people from using PHP which is another
effect turning off register_globals will have.
Java does not have this problem because Java is
From: [EMAIL PROTECTED]
Operating system: Linux 2 2.16
PHP version: 4.0.6
PHP Bug Type: Reproducible crash
Bug description: Disturbing memory corruption/crash
I've been attemping to track down a case of memory corruption that showed
itself with 'new ClassName' returning
Zeev Suraski wrote:
Anyway, to be more constructive - Andi had an idea when we were catching a
cab earlier today (yesterday). His idea (which I'm just pitching, we
haven't thought this through at all yet) is that instead of having
register_globals on, or off, we would have it as unset, by
Apologies in advance to Zeev for arguing on this one, but be assured I firmly
believe that your solution would be to the detriment of PHP and a better
solution is possible :)
On Saturday 28 July 2001 12:44, Zeev Suraski wrote:
NO!! :) Saying people would stop using PHP (or won't get
Zeev
If the thread safety stuff you've just committed might fiz the ISAPI
problems, and you want some testing doing, please shout out.
Cheers
--
Phil Driscoll
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
ID: 12425
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Open
Bug Type: Apache related
Operating System: Linux - Red Hat 7.1
PHP Version: 4.0.6
New Comment:
The Config Command Line (Per Request by Sniper):
./configure
From: [EMAIL PROTECTED]
Operating system: Windows 98 SE
PHP version: 4.0.6
PHP Bug Type: GD related
Bug description: I've tried inserting my php.ini file in five locations and it won't
load it
I've put then extention modules in a directory on my C Partition named
php_mod,
ID: 12449
Updated by: lyric
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Analyzed
Bug Type: GD related
Operating System: Windows 98 SE
PHP Version: 4.0.6
New Comment:
Look in the first section of the output from phpinfo(), and there's a line like:
Configuration File (php.ini) Path
On Thu, 19 Jul 2001 03:01:03 +0200, jmmele [EMAIL PROTECTED]
wrote:
all the modules I compile are working but imap.so
I have found the same problem with PHP 4.0.6 - on two different Red Hat
Linux generations.
I know about all the tricks regarding --with-imap-ssl and
--with-imap-kerberos, but
PHP 3.0 Bug Database summary - http://bugs.php.net
Num Status Summary (543 total including feature requests)
===[*General Issues]==
4180 Open is_link returns false when target doesnt exist (should return true)
9610 Bogus
On Sat, 28 Jul 2001, Zeev Suraski wrote:
BTW, I'm just being argumentative here. I personally think that having
E_NOTICE on is a very good idea, and that apps should be E_NOTICE-clean. A
great deal of PHP programmers will not agree with me, though, so I haven't
made up my mind on whether I
I recently updated autoconf to version 2.52 and now I get this
with running ./buildconf
rebuilding main/php_config.h.in
./aclocal.m4:929: error: m4_defn: undefined macro:
_m4_divert_diversion
./aclocal.m4:472: PHP_SUBST is expanded from...
./aclocal.m4:929: the top
Sebastian Bergmann wrote:
I recently updated autoconf to version 2.52 and now I get this
with running ./buildconf
Never mind, Sascha just told me to stick to 2.13.
--
Sebastian Bergmann Measure Traffic Usability
http://sebastian-bergmann.de/
From: [EMAIL PROTECTED]
Operating system: Red Hat Linux 6.2
PHP version: 4.0.6
PHP Bug Type: Recode related
Bug description: Segfaults if recode is loaded after mysql or imap
PHP segfaults if recode.so (php's recode extension as a shared library) is
loaded _after_ the imap
ID: 12439
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Closed
Bug Type: Filesystem function related
Operating System: Linux-2.2.19
PHP Version: 4.0.6
New Comment:
I found the problem. My DNS was broken.
Previous Comments:
Cannot load /usr/local/apache/libexec/libphp4.so into server:
undefined symbol: TSRMLS_FETCH
./configure --enable-inline-optimization
--with-apxs=/usr/local/apache/bin/apxs
--with-mysql=/usr/local/mysql
--with-pgsql
--with-zlib=/usr
Did you update TSRM Zend?
Andi
At 09:21 PM 7/28/2001 +0200, Sebastian Bergmann wrote:
Cannot load /usr/local/apache/libexec/libphp4.so into server:
undefined symbol: TSRMLS_FETCH
./configure --enable-inline-optimization
--with-apxs=/usr/local/apache/bin/apxs
Andi Gutmans wrote:
Did you update TSRM Zend?
Yes, of course. And I did a clean build, too. You're Andi, right?
Not Zeev in disguise? :-)
--
Sebastian Bergmann Measure Traffic Usability
http://sebastian-bergmann.de/http://phpOpenTracker.de/
--
PHP
As a matter of fact it doesn't, on its own, fix too much. It makes the
thread safe code much faster and a bit more centralized, which should help
improve the thread safety code to stability. There are more improvements
coming on this front soon :)
At 06:07 28/07/2001, Phil Driscoll wrote:
- My mind is pretty firm about implementing shortcuts for
$HTTP_*_VARS. People are going to rebel big time if we remove their global
variables by default, and make them use these exceptionally long
alternatives instead. Most people I talked to (virtually all of them
except for you :) agreed
Hey,
I thought of an idea yesterday which could make everyone happy. In the
default php.ini we set the register_globals to a new value unset. If PHP
runs with this INI value it will display a page telling you that you need
to define the register_globals option in your php.ini and explains the
From: [EMAIL PROTECTED]
Operating system: Linux 2.4.7
PHP version: 4.0.6
PHP Bug Type: Compile Failure
Bug description: compilation halts on libmysql extension
make[1]: Entering directory
`/usr/local/src/php-4.0.6/ext/mysql/libmysql'
/bin/sh
Björn Schotte wrote:
* Rasmus Lerdorf wrote:
significantly more secure PHP scripts out there. It will simply cause
scripts to break in non-obvious ways and the knee-jerk fix will be to
swear at those annoying PHP folks and then turn register_globals on, or
they will do something like:
Anil Madhavapeddy wrote:
Alexander Merz wrote:
Please, could you use relative specifications (font-size: small)
instead of absolute (font-size: 11px) in the css? It's more
user-friendly and i don't have to look for my eyeglasses each time.
Unfortunately, this isn't consistent
On Saturday, July 28, 2001, at 12:52 PM, Zeev Suraski wrote:
At 06:01 28/07/2001, Phil Driscoll wrote:
I and no doubt thousands of others will turn
register_globals on because it gives much more readable code,
much less
typing and does not IMHO add one jot to the security of my
From: [EMAIL PROTECTED]
Operating system: Linux 2.4.3 (Mandrake)
PHP version: 4.0.6
PHP Bug Type: Unknown/Other Function
Bug description: Parsing error in eval function
Using a buffer variable to collect HTML output as the
script progresses, at the end of the script using
From: [EMAIL PROTECTED]
Operating system: Win2k
PHP version: 4.0.6
PHP Bug Type: Scripting Engine problem
Bug description: comparing 0==null is true?
If you compare the integer(0) to the string null, PHP thinks they are the
same.
Am I hopped up on goofballs, or whats up
The best thing about PHP is that it has such a shallow learning curve that
non-programmers can write web apps.
The worst thing about PHP is that it has such a shallow learning curve
that non-programmers write web apps.
That is of course oversimplifying things quite a bit, but it is the root
of
36 matches
Mail list logo
