Title: AW: Bug #8780 Updated: difference in fwrite with cgi/apachemodule
I don't use PHP anymore in CGI mode. I only use it as an Apache Module, so I don't know, if it's still like mentioned below.
-Ursprüngliche Nachricht-
Von: Bug Database [mailto:[EMAIL PROTECTED]]
Gesendet:
ID: 12485
Updated by: dbeu
Reported By: [EMAIL PROTECTED]
Old Status: Analyzed
Status: Closed
Bug Type: Program Execution
Operating System: windows 2000
PHP Version: 4.0.6
New Comment:
this issue has already been fixed in cvs, look for exisiting bug reports before
submitting new!
dir isn't a
ID: 11649
Updated by: dbeu
Reported By: [EMAIL PROTECTED]
Old Status: Duplicate
Status: Closed
Bug Type: Program Execution
Operating System: Win98
PHP Version: 4.0.6
Previous Comments:
[2001-07-23 11:44:32] [EMAIL
Only in php-4.0.6.ORIG/Zend: zend_alloc.2.c
Only in php-4.0.6.ORIG/Zend: zend_alloc.2.c~
Only in php-4.0.6.ORIG/: cgi_build
Only in php-4.0.6.ORIG/ext/bcmath: number.c
Only in php-4.0.6.ORIG/ext/bcmath: number.h
diff -ur php-4.0.6.ORIG/ext/odbc/php_odbc.c php-4.0.6/ext/odbc/php_odbc.c
---
--- php-4.0.6.ORIG/Zend/zend_alloc.c Tue Jun 19 20:04:53 2001
+++ php-4.0.6/Zend/zend_alloc.c Tue Jul 31 10:32:39 2001
@@ -158,12 +158,11 @@
HANDLE_BLOCK_INTERRUPTIONS();
if (!p) {
- fprintf(stderr,FATAL: emalloc(): Unable to allocate %ld bytes\n, (long) size);
+ fprintf(stderr,FATAL:
From: [EMAIL PROTECTED]
Operating system: linux
PHP version: 4.0.6
PHP Bug Type: Arrays related
Bug description: array_unique function changed
My ISP recently upgraded from 4.0.3pl1 to 4.0.6 - i have a script that runs
an 'array_unique' on a 2d array. This used to work
At 09:05 02/08/2001, Andrei Zmievski wrote:
On Thu, 02 Aug 2001, Zeev Suraski wrote:
It's only going to affect the TS build, so most extensions will be left
unharmed. At any rate, leaving stuff for 4.1 has always been a way of
saying 'maniana' in our group... As far as I'm concerned, we
ID: 11935
Updated by: kalowsky
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Closed
Bug Type: ODBC related
Operating System: Linux RedHat 6.2
PHP Version: 4.0.6
New Comment:
no user feedback. if this bug still exists, please reopen
the bug.
Previous Comments:
It's time to break the evil spell on the middle number.
IMO, it does really matter if it is 4.1.0 or 4.0.7..
It's the HEADS UP! for people when you change the more significant
version number.
(and also gives a nice backdoor for breaking bc without wtf-factor :)
If someone is afraid of changing
On Thu, 02 Aug 2001, Jani Taskinen wrote:
Some things seem to be tested many times in same configure run.
I would be against removing config.cache on every configure run. Many
people configure PHP multiple times a day during development and this
slows it down. We should rather see what problems
It should be fairly easy to support both codebases by just defining the
right things depending on the API_NO. At any rate, whether we call it 4.1
or 4.0.7 doesn't really matter. It had to be done, and would involve the
same kind of issues regardless of the name.
Zeev
At 06:47 02/08/2001,
At 10:40 02/08/2001, Jani Taskinen wrote:
True. So you're saying that the people who write extensions should also
be following [EMAIL PROTECTED] to know about any major changes?
I guess most of them are; Those who aren't will bump into these issues as
soon as they try to upgrade. It's not
The register_globals change must go through one iteration where we have the
new APIs available, but still haven't changed the default. So, we can't
combine these two changes together...
Zeev
At 10:41 02/08/2001, Sebastian Bergmann wrote:
Zeev Suraski wrote:
- For the register_globals
From: [EMAIL PROTECTED]
Operating system: Compaq Tru64 UNIX 5.1 patch 3
PHP version: 4.0.6
PHP Bug Type: Compile Failure
Bug description: Fatal Error: No definition for inline function: scan_set_error_return
cc -I. -I/usr/local/src/php-4.0.6/ext/standard
ID: 12536
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Feedback
Bug Type: Performance problem
Operating System: win 98 box
PHP Version: 4.0.4pl1
New Comment:
Have you tried with PHP 4.0.6? And could you also
add a short example script into this bug report?
On Thu, Aug 02, 2001 at 12:24:03PM -0400, George Schlossnagle
wrote:
On a related note, placing null-bytes in the middle of strings
(for example
in the names of the so-called lambda_functions generated from
create_function()) seems like a pretty questionable practice.
why, this makes
Yes, this wouldn't be a new branch, just the next version.
On Thu, 2 Aug 2001, Jon Parise wrote:
On Thu, Aug 02, 2001 at 10:50:07AM -0700, Rasmus Lerdorf wrote:
I would pretty much insist on the _GET() stuff, import_globals() and
register_globals changes being implemented in 4.1. With
From: [EMAIL PROTECTED]
Operating system: win98
PHP version: 4,0,6
PHP Bug Type: Performance problem
Bug description: tiwizi
MISTER
lorse that I clic with the right button of smiles on the racourci EasyPhp
which on my bar of state I obtien:
Fichier Log: erreur
On Thu, 2 Aug 2001, Rasmus Lerdorf wrote:
Zeev Suraski wrote:
- For the register_globals default change, I believe a major
version bump is a very good idea, as it's exactly the kind of
heads-up message we want to send to all of the users.
Why not combine the two for a 4.1
TA Does the lack of comments mean that I may commit the patch? (I think
TA that I still have CVS access.)
I was pretty busy last week, sorry, so I couldn't look at it thoroughly.
But on the quick glance your patch looks OK.
TA By the way:
TA I think that the decbin() function should bail out if
The work which will have to be done is the author, not all of the
users. So the 10K number is not all that relevant.
At 10:50 02/08/2001, George Schlossnagle wrote:
Yes, I was counting those too... It's still not a very large number
(probably in the range of dozens, or hundreds at the
--- Stig S. Bakken [EMAIL PROTECTED] wrote:
[...big snip...]
If we add a log function, does anyone want to
guess how many scripts
will break because of it? :-)
Hmm, we have had a natural logarithm function (log)
since back in PHP3, in fact the availability of those
functions is what make me
ID: 12531
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Open
Bug Type: IMAP related
Operating System: RedHat 7.1
PHP Version: 4.0.6
New Comment:
uname -a produces the following:
Linux pisces.maurand.com 2.4.2-2 #1 Sun Apr 8 19:37:14 EDT 2001 i586
On Thu, Aug 02, 2001 at 10:50:07AM -0700, Rasmus Lerdorf wrote:
I would pretty much insist on the _GET() stuff, import_globals() and
register_globals changes being implemented in 4.1. With these TSRM
changes, the register_globals changes and hopefully Sterling's XSLT
changes I think there
From: [EMAIL PROTECTED]
Operating system: windows98
PHP version: 4.0.4pl1
PHP Bug Type: *General Issues
Bug description: CGI Error
As per the manual configaration has bean Done
when i try to acess first.php
i get the following Error message .
CGI Error
The
PHP needs a faster serializer and deserializer. It should be possible
to make one that is at least as fast as Zend compiling and executing
code defining the same structure.
Does anyone else want a faster serializer? Anyone interested in
contributing to a fund so we can set up a prize for the
I have already commited a change that if I file isn't found in the
include_path then PHP will check for the file in the running scripts' cwd.
Andi
At 07:36 AM 8/3/2001 +0200, Stig S. Bakken wrote:
Hi,
I would like to suggest that we change how . in the include_path is
treated to being
A while ago someone just said that they could not see any more Zend API
changes coming. I said that moving extensions to PEAR could not happen
until Zend's API either stabilizes, or at least tries to be backwards
compatible.
Obviously this won't be the case for a while yet. How do you propose
28 matches
Mail list logo
