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 PROTECTE
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.
--- 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 prev
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
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 changin
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, An
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 so
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 def
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
-I/usr/local/src/ph
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?
--Jan
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. Wi
ID: 12426
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: HTTP related
Operating System: RedHat Linux 7.0 2.2.16-22smp
PHP Version: 4.0.6
New Comment:
Well, some days ago I had tried to patch PHP myself. No result :-( I have found that
PHP does not get PO
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 Ap
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 tw
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
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
Binary compatibility was broken long ago in 4.0.7.
At 07:09 02/08/2001, [EMAIL PROTECTED] wrote:
> > On Thu, 02 Aug 2001, Zeev Suraski wrote:
> > > zeevThu Aug 2 09:16:20 2001 EDT
> > >
> > > Modified files:
> > > /Zend zend.c zend_execute_API.c zend_hash.c zend_hash.h ze
--- "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
ID: 11846
Updated by: andy
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Closed
Bug Type: Compile Failure
Operating System: NCR WM 4300 unix systema V MP-RA
PHP Version: 4.0.6
New Comment:
no user feedback.
Previous Comments:
ID: 12531
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: IMAP related
Operating System: RedHat 7.1
PHP Version: 4.0.6
New Comment:
One more thing. The RedHat php-imap package works. However, it does not have gd
support which is the first thing that I'm
> 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 release? How much work would be
> required
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 ther
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 speci
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 fa
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 re
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
f
32 matches
Mail list logo
