On Wed, 2 May 2001, Zeev Suraski wrote:
The question is, if you think people will actually download the RC in order
to test it (as opposed to using it) - why won't they join the QA team?
Their job description might list test new software releases
before putting them into production,
Their job description might list test new software releases
before putting them into production, and not join the PHP
QA team.
Testing new software releases before putting them into production is
pretty much a one sentence description of what 'Quality Assurance' is.
The
I would rather describe QA as Making sure the release does have as least
bugs as possible. IMO this is different then just testing RC's. I think a
QA team should be the team who says Yes, release it or No, there are
still some bugs left we want to fix. Of course, in order to do this, they
On Fri, 27 Apr 2001, Andi Gutmans wrote:
Larry,
You are right if this code refers to the POSIX semantics of readdir_r.
However, this code is in #if defined(HAVE_OLD_READDIR_R) and I don't know
what is meant by old readdir_r (different semantics?).
Sascha? Can you shed some light on this?
So what does that mean? The code is OK there and it isn't reached on
systems where readdir_r returns 0 for success? I'm not quite sure what to
do with this bug report.
We either need to differentiate between Solaris and HPUX
readdir_r or ignore the return value of that system call, as
On Tue, 24 Apr 2001, Zeev Suraski wrote:
At 03:02 24/4/2001, Anil Madhavapeddy wrote:
It a bit of a showstopper for pretty much all web-based mail clients
like IMP - people have been reporting their logs being littered with
segfaults for a while now actually.
Ok then, merge it in, and
On Mon, 16 Apr 2001, Jason Greene wrote:
If not this idea, what about a symbolic link for
/usr/local/lib/php/extensions/current to the correct dir?
There is no single correct dir. We would not need this long
path, if there would be such a directory which is correct in
all
On Fri, 13 Apr 2001, Andi Gutmans wrote:
Does this work for you on 4.0.4pl1?
Any idea when this broke?
Andi
The following commit broke this functionality:
date: 2001/03/11 10:08:27; author: sasha; state: Exp; lines: +17 -1
branches: 1.148.2;
Fixed a compatibility problem
Ok, my fault - I will add test if this is a file handle and not if this
is not a socket handle.
Yes, that would be a possible solution.
How this should be solved on AIX?
The last sentence referred to that ANSI incompatibility which
(so far) I have only seen on AIX. It looks
Okay, what about making libphp4.la contain everything but libsapi.la,
and make a new final target including libsapi.la called
libphp4_xxx.la, where xxx is the sapi module used.
With some more minor restructuring, we can then let people build _all_
sapi modules in one go if they like.
On Wed, 11 Apr 2001, James Moore wrote:
What are we doing with the current release right now?
who is having problems and which problems are outstanding??
a single compiler warning issue - in ext/standard/exec.h there must be a
declaration of php_Exec:
int php_Exec(int type, char
the idea is that it would be better if the line above is included in
exec.h... of course it works without it but at least i am not happy with it
this way.
You would be perfectly right, if we would be dealing with the
main branch of CVS. In the case of the release branch, many
Sascha, what symbols can sneak in to break linking? A few examples I
can test with would be nice.
As other people on this list have mentioned, building
--with-apxs illustrates the breakage.
The chosen SAPI module (i.e. sapi/apache/libsapi.la) is part
of libphp4.la. Usually,
4. The CGI version of PHP is always built and installed.
I think this should be optional.
- Sascha Experience IRCG
http://schumann.cx/http://schumann.cx/ircg
--
PHP Development Mailing List http://www.php.net/
To unsubscribe,
On Mon, 9 Apr 2001, James Moore wrote:
4. The CGI version of PHP is always built and installed.
I think this should be optional.
Perhaps optionally disabled.. --without-cgi?
First, it is a boolean feature, hence enable/disable would be
correct. Second, defaulting to the
On Mon, 9 Apr 2001, Anil Madhavapeddy wrote:
Derick Rethans wrote:
I would go for optionally on, I really dont want to build both
the apache module (p.e.) AND the CGi at the same time.
For QA testing this is fine, but not for production servers.
Well, it really beats the alternative,
My knowledge of C portability is weak in these cases, but the
following patch appears to fix things here. Can some of you more
knowledgeable folks give this a quick look and let me know if it's
okay for me to commit this?
+1
- Sascha Experience
If register_globals is set to on, you cannot access $HTTP_SESSION_VARS any
longer. Instead you can get the values through implicit created variables or
through the $GLOBALS array.
Unless a bug has slipped in, HTTP_SESSION_VARS get always
created. If you enable register_globals,
On Fri, 6 Apr 2001, Cameron wrote:
current snap:
Fixed
- Sascha Experience IRCG
http://schumann.cx/http://schumann.cx/ircg
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For
But I didn't want to commit this change into it yet before hearing
whether it's the proper way to handle the old arg_separator problem:
Looks good.
- Sascha Experience IRCG
http://schumann.cx/http://schumann.cx/ircg
--
PHP
Is there a reason the $'s were escape, or can I commit my fix?
If EXTENSION_DIR/INCLUDE_PATH are used outside makefiles,
your patch should be applied.
- Sascha Experience IRCG
http://schumann.cx/http://schumann.cx/ircg
--
Possibly not - can the original poster comment?
He wrote
If register_globals is set to on, you cannot access $HTTP_SESSION_VARS any
longer. Instead you can get the values through implicit created variables or
through the $GLOBALS array.
'access' and 'get' sound like read operations to
It is simpler.
Chuck is talking about another problem which I agree has not
been addressed yet properly.
We should just leave the array $HTTP_SESSION_VARS in the
case when register_globals is on. Currently when the variables are registered
they *are* removed from the
On Wed, 4 Apr 2001, Jani Taskinen wrote:
sniperWed Apr 4 13:46:27 2001 EDT
Modified files:
/php4 php.ini-dist php.ini-optimized NEWS
/php4/ext/standardurl_scanner.c url_scanner_ex.re url_scanner_ex.c
/php4/mainmain.c php_globals.h
If so, why this change didn't find its way into PHP_4_0_5 branch? It was
done a week ago, at the time of ~ RC3 I think.
No need for anger. We can drop some simple backwards macros
into the head branch which output a warning, when called, but
work normally otherwise.
- Sascha
Yes, that's true. I did ask (couple of times) before
I committed that patch. And yes, now both and ; are
considered as arg separators.
And I'd like to think that it's a feature than bug. ;)
That would be true, if PHP would be some kind of reference
implementation. But we don't
1.3 is (I think) the official release version. However, we've only
upgraded to this in the past couple of days, version 1.2 had exactly the
same behaviour.
Thanks. I've committed a fix to the main branch which has
been tested on Darwin 1.2.
- Sascha
In my humble opinion (humility is a virtue), new modules are fine to add
while in the release process, as long as there's at least one RC after
them, to ensure they don't mess up the build or anything trivial like
that.
Oh, messing up the build is a trivial thing?
It takes 2-3 months
Yes, it is. Non trivial things are things that are difficult to find,
which require long and thorough testing, such as changes to core API
functions or very common modules. Figuring whether the build works or not
is trivial.
That might be true for a single build. We support dozens of
I don't think that there would be a real life situation in which a new
module would break a build under one platform, and won't under another
platform, without you actually using the module. The author has to be
exceptionally 'talented' to achieve that.
The config.m4 just has to reach a
As you may know, new scripts don't tend to be born with nuclear simulations
as their config.m4, as the gd extension grew to have during the years.
"don't tend" does not preclude the existance of such modules
in the future.
Guys, please play by the rules which are laid down in
I definitely don't agree with this definitely. A good thing about
opensource projects is that there aren't committees and thick rule books
that move and act at the speed of a dinosaur. When it begins to look that
way, you know you're in the wrong direction.
OpenSource does not mean
The bottom line is that, as I said, the trick in good opensource software
is taking calculated risks, and mixing agility with quality assurance. One
can look through your binary glasses, and then it's either complete lack of
quality, or complete lack of risks, and one can look with
I think most (probably not all) pl's were sparked due to security bugs
which were found and we took the opportunity to add another couple of
important fixes. Those kind of pl's would not have been prevented by any
Great Plan.
If I remember correctly, 4.0.4pl1 was the only release
On Wed, 21 Mar 2001, Andi Gutmans wrote:
A couple of these were buffer overflows IIRC which were security issues.
Remember the group@ emails about those?
Fixes against format-string attacks and for file-upload
issues went into 4.0.3. Or what are you referring to?
- Sascha
The Apache module issue was a security problem. A fairly major one, too.
Yes, that is why I mentioned 4.0.4pl1 as an exception in an
earlier email.
- Sascha Experience IRCG
http://schumann.cx/http://schumann.cx/ircg
--
On Wed, 21 Mar 2001, Andi Gutmans wrote:
Why do we need to have an interrogation. Relax, it's not such a big deal.
I'm completely relaxed. I just dislike twisting history.
- Sascha Experience IRCG
http://schumann.cx/
The SAPI extension was never used by anyone before so there's no harm in
adding it (this is not changing/patching existing functionality).
It does make two changes to two build files but I took a very close look at
them and it doesn't seem like they can cause us problems.
Regardless of
On Fri, 16 Mar 2001, Adam Dickmeiss wrote:
OK, see http://www.php.net/bugs.php?id=9766edit=1
Thanks.
In order to exclude bugs in the compiler/C library, can you
please give this version a try?
http://schumann.cx/ircg/ircg-2.1-x86-linux.tar.gz
You can replace your thttpd
Hi Adam,
the good thing is that the binary works! I am, however, still
unable to produce a binary myself that doesn' crash.
I've tried to upgrade to glibc 2.1.2 from 2.1.1. I've also tried
to recompile the whole thing on a Redhat 7.1 beta (Fisher) with kernel
2.4.2-ac3 and glibc 2.2.1-3
Hi,
Program received signal SIGSEGV, Segmentation fault.
0x80ef6e5 in irc_cmd_RPL_NAMREPLY (conn=0x8189bb0, msg=0x401f591c)
at irc_dispatcher.c:181
181 {
can you please provide further information by appending it to
the bug report?
What kind of optimization are you
(note that this thread is off-topic. This list is about
developing PHP, not developing with PHP. Further emails
on this topic should be send to php-general.)
A possible cause is passing a string to header (or SetCookie)
which contains a CRLF.
header("Foo: bar\r\n");
On Wed, 14 Mar 2001, Jason Greene wrote:
Hi Sascha,
Look at 7.23.2.6 Normalization of broken-down times
Which version of the "Ansi C standard" are you referring to?
C99 (ANSI/IEC/ISO 9899:1999) does not contain such a section
nor does it contain the term normalization.
The
On Wed, 14 Mar 2001, Jason Greene wrote:
I think i was looking at a draft,
is there anything in the your copy oflC99 that resembles?:
7.23.2.6 Normalization of broken-down times
Jason,
[#1] A broken-down time is normalized by the mkxtime
Hi,
Either way though, you are saying that this has not been
excepted into the final C99?
Correct. A bit of googling brought up this page where Paul
Eggert documents why the proposal is broken.
http://www.cl.cam.ac.uk/~mgk25/c-time/comment-eggert.html
So should we depend
Any ideas where such instructions could be found, or how to force
"configure"
make a static module ?
We have an extension generator which creates the basic
"infrastructure" for a new extension. The result can be
build as a static module or as a shared module.
Try
On 8 Mar 2001 [EMAIL PROTECTED] wrote:
ID: 9223
Updated by: stas
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: Recode related
Assigned To:
Comments:
Seems that this is a recode memory leak, not PHP's. At least
Insure says that recode library is leaking
On 3 Mar 2001 [EMAIL PROTECTED] wrote:
From: [EMAIL PROTECTED]
Operating system: Debian Linux 2.2.r2
PHP version: 4.0.3pl1
PHP Bug Type: *Session related
Bug description: automatic extention of links fails with 'http://www...'
Hi,
the automatic extension of links
On Mon, 26 Feb 2001, Wez Furlong wrote:
Ahhh.
Well, I'll settle for my email address being corrected in the meantime (I
have left my former employer),
and let the terrorists, um, core guys up my karma when it's really needed.
Can someone with enough rights amend the email address to
If noone objects, I'll rename those files in a couple of
hours using a CVS mv, so their history is preserved.
Will you be moving the fopen-wrappers.[ch],v files or will you be
copying them to their new names and 'cvs delete'ing them from the HEAD
branch?
The former.
I've
On 23 Feb 2001, Ian Holsman wrote:
Hi.
I was wondering if anyone was planning to update the apache 2 drivers in
CVS.
There seems to have been a couple of function call name changes,
which can make it compile, but it seems to not respond, so I don't think it
is that simple..
AFAICT
Hi,
thanks for your patches. I've already applied some of them.
[..]
host_info = gethostbyname(host);
But host is const char *. So I had to change line to as follows:
host_info = gethostbyname((char *)host);
Then your system header files are broken. The correct
prototype
On Wed, 7 Feb 2001, Boian Bonev wrote:
hi,
i've seen the same really soon and could track it:
Cool, I looked further down the specific config.m4 and it
appears that the zlib check was copied and not modified
correctly. Fix committed.
- Sascha
--
PHP Development Mailing
On Tue, 6 Feb 2001, Rasmus Lerdorf wrote:
This might be workable. I fear Sascha's solution could be rather prone to
mistakes, and it would slow down list delivery for everyone. Requiring
approval for non-list members is a hassle for them, but if enough people
are willing to be on the
i know i can make clean or even distclean but it is not nice...
try make depend.
- Sascha
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail:
On Tue, 6 Feb 2001, Derick Rethans wrote:
Hey,
rather strange error in the ./configure script. I think it's from
--with-dom. However, everything works fine.
That is probably caused by a construct like
PHP_ARG_WITH(foo, ..)
..
AC_ADD_LIBPATH($PHP_FOO/lib)
I.e. when
On Wed, 7 Feb 2001, Derick Rethans wrote:
On Wed, 7 Feb 2001, Sascha Schumann wrote:
Please post your full configure line.
Ok, those are quite a lot entries. Did you add one recently?
When did you see that kind of error for the first time? Did
you change anything related
On Tue, 6 Feb 2001, Toby Butzon wrote:
Although I agree, I don't think it's ever going to happen. Somehow, the
head PHP folks don't seem to be too interested in combatting spam; I
brought up the discussion a few weeks ago and was met with strong
resistance.
You'd be surprised to learn
On Thu, 1 Feb 2001, Jani Taskinen wrote:
The emails sent by the bug system now have a note
about _not_ replying to the emails but using the web interface instead.
I would like to see that everybody who handles the bug reports
used the web interface instead of directly replying with their
Users are in no way forced to use the web interface, they'll still be able
to send mail with their client. Jani only means that problems, questions
and feedback must be registered, so that things are much easier to track
down. And I think this is a good idea.
And that is the issue. The
On Fri, 26 Jan 2001, Sam Liddicott wrote:
Why are le_* garbage destructor handles declared static?
As far as I can tell this means other c files in the same module can't
"extern" it but as it is static in file scope it has none of the other
benefits of being static?
Is it to do with
Is:
AC_ADD_LIBRARY(stdc++)
also my responsibility in config.m4? [My associated 3rd party .a's seem to
require it]
Not necessarily. Do you need to perform any linkage tests in
your config.m4 with that third party library?
- Sascha
--
PHP Development Mailing List
No, Idon't do any linkage tests; but if I don't do it, at php link time I
get errors of various istream, ostream etc unresolved links. If I do it, it
links fine.
Perhaps we should provide a macro for that purpose, as the
standard C++ library is available under various names:
Hi,
please consider this part of a form:
input name="Data[user][foo]" type="text"
input name="Data[user][bar]" type="file"
The file upload code adds Data[user][foo] properly to
HTTP_POST_FILES. But then, it tries to add variables like
these:
[hate to reply to myself, but I don't want to waste other
people's time looking into this thing.]
I think I've found the bug.
The comment in rfc1867.c around line 195 says:
start_arr is set to point to 1st [
But the code use strrchr to locate the bracket, so
On 19 Jan 2001 [EMAIL PROTECTED] wrote:
ID: 8803
Updated by: derick
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: Unknown/Other Function
Assigned To:
Comments:
This works fine:
echo sprintf ("%2x", 29);
output:
1d
This is not a bug.
Does %.2x
/bin/sh: I.: command not found
make[4]: [muscatapi.lo] Error 127 (ignored)
Your config.m4 lacks PHP_REQUIRE_CXX.
- Sascha
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the
On Sat, 20 Jan 2001, Jani Taskinen wrote:
Test script:
?php session_start(); ?
There is probably something broken in your checkout or build.
The latest CVS works fine here.
- Sascha
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
On Thu, 18 Jan 2001, Derick Rethans wrote:
Configure gives this when configuring with the latest CVS:
Try running buildconf. Those files have been moved weeks
ago.
- Sascha
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For
On Wed, 17 Jan 2001, Sam Liddicott wrote:
Midgard, soon to use php4 is to be released GPL (according to their website
www.midgard-project.org).
How will this work; will it just be the patch to php4 that makes it INTO
migard that will be GPL, or midgard+PHP that will be GPL.
The owner
On Tue, 16 Jan 2001, Christophe Thibault wrote:
Actually, it's not that dangerous as the redefinition of errno only occurs
in fsock.c and errno is only used in fsock.c for retrieving socket errors...
Something like this is more safer:
#ifdef PHP_WIN32
#define php_sock_errno()
Shouldn't php.ini entries overwrite defaults and become the
master value?
That is what happens currently: php.ini entries are applied
using zend_alter_ini_entry(), and the default value is stored
in orig_value. On the next request shutdown,
zend_deactivate() calls
register_ini_entries(), which is the service function that modules use to
register their entries, doesn't use alter_ini_entry(). It checks the
configuration hash (=php.ini) for a default value. If it exists, it uses
it as the default value (it doesn't use alter_ini_entry()), if it doesn't -
On 9 Jan 2001 [EMAIL PROTECTED] wrote:
From: [EMAIL PROTECTED]
Operating system: Linux/RedHat 7.0
PHP version: 4.0.4
PHP Bug Type: *Session related
Bug description: --enable-trans-sid does not work on html img tag
In 4.0.4 the SID is not inserted into the HTML code
401 - 474 of 474 matches
Mail list logo
