date:20010924

Re: [PHP-DEV] curl compiler failed

2001-09-24 Thread Sterling Hughes


On Mon, 24 Sep 2001, Stanislav Malyshev wrote:

> SH>>
> SH>> Yes, but it also affects the portability of apps when using cURL,
> SH>> you have to worry not only which php version supports which
> SH>> features, but also which curl version linked with php supports these
> SH>> features, this is a real headache.
>
> No, quite the opposite - if the only thing you have to worry about would
> be installed cURL version and not PHP version (or if you could just write
> something like requires(curl >= 7.7.2) - just like RPM does, for example)
> - it would be easier. Especially taking into account that generally you
> hardly know which version of curl which PHP supported - how exactly many
> people know which constants were in with PHP 4.0.3/cURL without
> looking into the CVSweb? Probably less than two.
>

This is not so...  If I write code that goes:

if (phpversion == 4.0.8) {
curl_setopt($ch, CURLOPT_SSL_VERIFYRESULT, 1);
}

I'd expect it to work with all php's above 4.0.8, the only problem
is that if you link PHP 4.0.8 with an older version of CURL this
will cause PHP compilation errors that maybe unforseen, therefore,
to right it truly portable, you need two version checks for each new
piece of code.

if (phpversion == 4.0.8 && curl_version == 7.9) {
curl_setopt($ch, CURLOPT_SSL_VERIFYRESULT, 1);
}

which makes writing portable code a real bitch...  This was a
problem that many users were having when one version of php
supported differed in support for a wide range of cURL constants
from another.  Its much easier if configure barfs, this is an
explicit error, and you only have to fix it once.

> That brings us to capabilities discovery and versioning discussion, which
> deserves its own topic and serious attention, outside this small issue I
> brought up. Maybe someone has to write an RFC for this.
>
> In any case, if you feel that it is absolutely necessary to support this
> constant in PHP, even though no cURL release still has it, please insert
> the relevant configure check. It is the real pain to go through three
> screens of gcc wailings each time and recompile it again just to discover
> yet another constant missing. (it would be also pretty much pain to have
> latest CVSes of 10+ packages just to be able to compile CVS PHP, but I
> talked about this already).
>

cURL 7.9 was released today, I'll add a configure check.

-Sterling


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] RC3

2001-09-24 Thread Stig Venaas

On Mon, Sep 24, 2001 at 10:40:04PM +0200, Zeev Suraski wrote:
> If it's a bug fix you believe to be important and the chances, in your 
> opinion, of it screwing things up more than it fixes are slim, go ahead and 
> commit it...

Maybe I've already done what's needed, I'm not quite sure how this
works. I thought there would be a php_4_0_7 tag for ldap.c but I
can't find any. Does that mean that what I added will be in? In
RC2 1.94 of ldap.c is used, my change is 1.96 and 1.95 is just
vim cosmetics, no code change.

So, my guess is that latest ldap.c will be in 4.0.7 since no branch.
Let me know if I should do anything, and sorry for my poor CVS skills.

Are there any LDAP testing done on the RCs? I'm surprised no problem
was detected. We do have a set of automated tests, right? I can make
some LDAP tests if needed. One problem is that there are many LDAP
APIs, the best is perhaps to test with OpenLDAP 2 which I think is
the most widely used.

Stig

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] class destructors?

2001-09-24 Thread Martin Jansen


On Mon, 24 Sep 2001 14:49:53 -0400 (EDT), [EMAIL PROTECTED] wrote:

>Just a thought. I have been using PHP for a while now, and have wondered why
>it does not support class destructors? It would be a very useful thing.

Have a look at PEAR: We are using register_shutdown_function() to emulate
destructors. If you have more questions concerning this topic, you should
ask them on [EMAIL PROTECTED]

- Martin



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #13425: invalid page fault in module PHP4TS.DLL

2001-09-24 Thread thunder2


From: [EMAIL PROTECTED]
Operating system: Windows 98 SE
PHP version:  4.0.6
PHP Bug Type: Reproducible crash
Bug description:  invalid page fault in module PHP4TS.DLL

Hello,

I'm running PHP 4.0.6 and Apache 1.3.19 localhost on Windows 98,
with the latest Zend Optimizer 1.1.0 (PHP 4.0.6 compatible).

PHPBuilder has an article on: Storing Binary Data with PHP/MySQL
(http://phpbuilder.com/columns/florian19991014.php3)

The scripts:

1) Create a new database on your SQL Server:

CREATE TABLE binary_data (
id INT(4) NOT NULL AUTO_INCREMENT PRIMARY KEY,
description CHAR(50),
bin_data LONGBLOB,
filename CHAR(50),
filesize CHAR(50),
filetype CHAR(50)
); 

2) A sample php script you can use to store data in your database:

   store.php


// Example php script to demonstrate the storing of binary files into
// an sql database. More information can be found at
http://www.phpbuilder.com/
?>


Store binary data into SQL Database


This file has the following Database ID: $id";

MYSQL_CLOSE();

} else {

// else show the form to submit new data:
?>


File Description:


File to upload/store in database:










3) A sample php script with which you can access the stored data  

   getdata.php


// Example php script to demonstrate the direct passing of binary data
// to the user. More infos at http://www.phpbuilder.com
// Syntax: getdata.php?id=

if($id) {

// you may have to modify login information for your database server:
@MYSQL_CONNECT("localhost","root","password");

@mysql_select_db("binary_data");

$query = "select bin_data,filetype from binary_data where id=$id";
$result = @MYSQL_QUERY($query);

$data = @MYSQL_RESULT($result,0,"bin_data");
$type = @MYSQL_RESULT($result,0,"filetype");

Header( "Content-type: $type");
echo $data;

};
?> 

As the script needs to "know" which file is requested, you have to add the
ID as a parameter. 
Example: A file has been stored with ID 2 in the database. To get this
file, you have to call: 

   getdata.php?id=2 

-

OK, the scripts work GREAT, but here is where I have a problem:

1) I go into phpMyAdmin (Version 2.2.0)
2) Select my database
3) BROWSE the table - binary_data
4) Select EDIT on one of the items within the table...


APACHE caused an invalid page fault in
module PHP4TS.DLL at 0177:00a3861b.
Registers:
EAX=00730ef8 CS=0177 EIP=00a3861b EFLGS=00010202
EBX=00736d74 SS=017f ESP=01a6f960 EBP=007bb270
ECX=1980 DS=017f ESI= FS=61a7
EDX=25303025 ES=017f EDI=0001 GS=
Bytes at CS:EIP:
8b 0a 89 88 34 2c 00 00 eb 18 6a 10 e8 54 2c fe
Stack dump:
01a6fe5c 007bb270 01a6fde4 007a3990 051a73f4 0080b7cc 0002 051a6fdc
051a700c   01a6fbcc 007c9b81 0009  01a6f9dc

APACHE caused an invalid page fault in
module PHP4TS.DLL at 0177:00a1b434.
Registers:
EAX=43254335 CS=0177 EIP=00a1b434 EFLGS=00010246
EBX=00736d74 SS=017f ESP=0194f944 EBP=007bb270
ECX=25364525 DS=017f ESI=007d5b20 FS=603f
EDX=45442545 ES=017f EDI=00730ef8 GS=
Bytes at CS:EIP:
89 02 8b 06 85 c0 74 06 8b 4e 04 89 48 04 56 ff
Stack dump:
051a6eec 007d5b30 00a1ff84 007d5b30 007f8ab0 00a33f22 00738534 0194fe5c
007bb270 0194fde4 007a3990 051a6ecc 008160ec 007f8ab0 051a6bbc 051a6bec

Oddly enough, even though I get these 2 warning (or errors),
Apache does NOT crash... I can continue to browse other
databases in phpMyAdmin, and Apache continues to serve web pages?

Any idea what might be causing this?

Steve

-- 
Edit bug report at: http://bugs.php.net/?id=13425&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #13424: imagecreatetruecolor() or imagecopyresampled()

2001-09-24 Thread gargouil


From: [EMAIL PROTECTED]
Operating system: mandrake 8
PHP version:  4.0.6
PHP Bug Type: PHP options/info functions
Bug description:  imagecreatetruecolor()  or imagecopyresampled() 

i use imagecreatetruecolor()  or imagecopyresampled() and i have an fatal
error caused by undefined function but i use verison 2.0.1 of GD.. on my
windows box this work well but in linux the same code don't work

answer quick.. thats urgent

thanks
-- 
Edit bug report at: http://bugs.php.net/?id=13424&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] [RFC] Versioning rules for PHP/Zend/PEAR/Extensions

2001-09-24 Thread Jim Winstead

On Tue, Sep 25, 2001 at 03:00:05AM +0200, Zeev Suraski wrote:
> First, you forget that for the vast majority of end users, treating RC's as 
> releases is going to be nightmarish.  RC's are a reality check before 
> release, and so far, we haven't had a single RC that was release 
> worthy.  Just imagine how much headaches we solved employing this approach.

you are misrepresenting what i said. in what i am saying, something
with a number is not automatically release quality, is not
automatically listed alongside other releases, and is in absolutely no
way different from what we currently tag with a version number that
happens to contain the string 'RC' in it.

(yes, we haven't had a 'pl' since 4.0.4. of course, that's just
because it was decided the memlimit fix for 4.0.6 didn't merit a 'pl'
designation. my point was simply that instead of ever making use of
that middle digit in our release numbers, we just sometimes tack on a
extra digit at the end, and that seems silly to me.)

and i do question, a little bit, how successful our new release
strategy is when we only seem to be able to muster a new release every
three months. but maybe that's a pace we're happy with. and of course,
that has way more to do with a great many more issues than how we
number the releases. :)

jim

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] [RFC] Versioning rules for PHP/Zend/PEAR/Extensions

2001-09-24 Thread Zeev Suraski

There are some customary rules with version numbers.  Ignoring them will 
result in lots of confusion, as most popular opensource projects use them 
(Linux, Apache, MySQL to name a few).  Major version number signifies the 
'generation', 2nd digit signifies major changes and/or big new chunks of 
functionality, and 3rd digit signifies small changes, small feature 
additions, and bug fixes.  Additional qualifiers are added under certain 
circumstances, if necessary (patch level, beta, etc.).

First, you forget that for the vast majority of end users, treating RC's as 
releases is going to be nightmarish.  RC's are a reality check before 
release, and so far, we haven't had a single RC that was release 
worthy.  Just imagine how much headaches we solved employing this approach.

Although pl's are a thing of the past, they weren't nonsensical at all, as 
you suggest.  When there were one liner fixes, which did not affect pretty 
much anything else (including binary compatibility, functionality and 
script-level compatibility), releasing a pl made very good sense.  That 
discussion is mostly hypothetical though, as we haven't had any pl's since 
we started using the RC mechanism, and it's no coincidence.  Going with 
your suggestion essentially recreates the problem (release unchecked code) 
and solves it, IMHO, in a bad way (release new bug-fix releases often).

Zeev

At 00:57 25-09-01, [EMAIL PROTECTED] wrote:
>Stig Sæther Bakken <[EMAIL PROTECTED]> wrote:
> > Huh?  Does strnatcmp() know the that 2.0RC4 is newer than 2.0b2? :-)
>
>probably not. i've always thought that the change needed to make php's
>version numbers make more sense is relatively small -- stop ignoring
>the middle digit, and use it to signify releases. so instead of
>4.0.7RC1, you'd get 4.1.0 (on BRANCH_4_1 or whatever). if bugs were
>found, 4.1.1 would get released. when one of those releases is deemed
>stable (what would be just 4.0.7 in our current scheme), make it
>available for download on the download page. (meanwhile, head
>development is on 4.2.0-dev.)
>
>this also avoids the '4.0.6pl1' nonsense we've had to do before, too.
>just release a new version in that 4.x branch.
>
>(and the number of cases where people should need to check version
>numbers for functionality should be vanishingly small. that's why we
>have things like function_exists().)
>
>i think tying the numbers to some definition of feature additions and
>bug fixes only provides fodder for rules lawyers. i believe the
>versioning scheme should be firmly rooted in the development process
>that actually exists, not some ideal of what it should be.
>
>jim
>
>--
>PHP Development Mailing List 
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>To contact the list administrators, e-mail: [EMAIL PROTECTED]

--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] CVS Account Request

2001-09-24 Thread CVS Account Request


Full name: Bernd Roemer
Email: [EMAIL PROTECTED]
ID:bernd
Purpose:   working on some PEAR-classes

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #13419 Updated: strtok doesn't properly work with "#" as a token

2001-09-24 Thread ckoontz


ID: 13419
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: Strings related
Operating System: linux 2.4.9 (debian unstable)
PHP Version: 4.0.6.7rc2
New Comment:

If this is bogus.. make sure you document the change...
doing strtok($moo,"#") worked fine in earler releases...
I'm fairly certian it worked in 4.0.6



Previous Comments:


[2001-09-24 16:17:00] [EMAIL PROTECTED]

This is not a bug. This is the way strtok() works. Although PHP uses its own 
implementation, strtok() under C works the same and PHP mimics the C version (anything 
else would render this function useless).

No bug, bogusifying.

If you need similar functionality take a look at explode()/split()

- Markus



[2001-09-24 15:29:53] [EMAIL PROTECTED]

in the following code:
$string = "#This is an example string";
$tok1 = strtok($string,"#");

$tok1 should equal nothing.. however it equals $string

This bug breaks ACID:
http://www.cert.org/kb/acid/

people on IRC have verified that this bug is also in CVS as of this report





Edit this bug report at http://bugs.php.net/?id=13419&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] [RFC] Versioning rules for PHP/Zend/PEAR/Extensions

2001-09-24 Thread jimw


Stig Sæther Bakken <[EMAIL PROTECTED]> wrote:
> Huh?  Does strnatcmp() know the that 2.0RC4 is newer than 2.0b2? :-)

probably not. i've always thought that the change needed to make php's
version numbers make more sense is relatively small -- stop ignoring
the middle digit, and use it to signify releases. so instead of
4.0.7RC1, you'd get 4.1.0 (on BRANCH_4_1 or whatever). if bugs were
found, 4.1.1 would get released. when one of those releases is deemed
stable (what would be just 4.0.7 in our current scheme), make it
available for download on the download page. (meanwhile, head
development is on 4.2.0-dev.)

this also avoids the '4.0.6pl1' nonsense we've had to do before, too.
just release a new version in that 4.x branch.

(and the number of cases where people should need to check version
numbers for functionality should be vanishingly small. that's why we
have things like function_exists().)

i think tying the numbers to some definition of feature additions and
bug fixes only provides fodder for rules lawyers. i believe the
versioning scheme should be firmly rooted in the development process
that actually exists, not some ideal of what it should be.

jim

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #13423 Updated: gethostbyname() returns hostname when ip address is part of hostname

2001-09-24 Thread jimw


ID: 13423
Updated by: jimw
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Analyzed
Bug Type: Unknown/Other Function
Operating System: 
PHP Version: 4.0.4pl1
New Comment:

actually, what is going on is that php's gethostbyname() simply returns the name when 
it can't be resolved. (that seems like rather silly behavior to me, and is probably 
worth changing.)

Previous Comments:


[2001-09-24 18:12:03] [EMAIL PROTECTED]

When you pass a host name such as ip-255-255-255-255.reverse.mobilenetics.com to 
gethostbyname() it returns the hostname, not the ip address.

Regular hostnames like google.com work.





Edit this bug report at http://bugs.php.net/?id=13423&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] [RFC] Versioning rules for PHP/Zend/PEAR/Extensions

2001-09-24 Thread Stig Sæther Bakken


[Andrei Zmievski <[EMAIL PROTECTED]>]
> On Mon, 24 Sep 2001, Jani Taskinen wrote:
> > 2. General rules for PHP, Zend and PEAR/C-extensions
> > 
> > 
> >   v.m.b (e.g. 4.0.8)
> > 
> >   v = Functions removed, function behaviour changed, API changes,
> >   major parts rewritten. (BC might be broken)
> >   m = New functionality added. Only backwards compatible API changes. (100% BC)
> >   b = Bug fixes. No new functions added. No API changes. (100% BC)
> >   Left out if zero (0).
> 
> It's going to be pretty tough to not add any functionality while also
> fixing bugs. Maybe 'b' could be incremented for bug fixes and minor
> functionality enhancements and 'm' for more extensive new functionality
> and API changes?

I think we should be flexible to make this practical, the core of the
idea is that you should not get any surprises when upgrading just "b",
and no API surprises when upgrading "m".

There's a question about whether the API should be defined as the
source API, or also the runtime API, for extensions.  I think "the
API" should cover both.

> > 3. Stable/development branches [OPTIONAL]
> > --
> > 
> >   Even minor number: stable (x.2.x) branch.
> >   Odd minor number : development (x.3.x) branch.
> > 
> >   (this is not needed for PHP. Our stable branch can be the
> >release branch and the development branch is just the HEAD)
> 
> Correct.
> 
> > 5. New PHP/Zend API function version_compare()
> > --
> > 
> >   proto int version_compare(string version1, string version2 [, string operator])
> > 
> >   This function knows this: 4.0.5 < 4.0.6RC2 < 4.1.4 < 4.2-RC1
> >   and returns:
> > 
> >   -1  version1  <  version2
> >0  version1 === version2
> >1  version1  >  version2
> 
> We already have such versions, they are called strnatcmp() and
> natsort().

Huh?  Does strnatcmp() know the that 2.0RC4 is newer than 2.0b2? :-)

> >   Extensions can use the same function internally to check the Zend / PHP
> >   versions.
> 
> How do we check PEAR versions, will PEAR class have a standard function
> that returns version?

We'll need to add something like that.  Either a function, a standard
method or when ZE2 comes a static class variable.

 - Stig

-- 
  Stig Sæther Bakken <[EMAIL PROTECTED]>
  Fast Search & Transfer ASA, Trondheim, Norway

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #13423: gethostbyname() returns hostname when ip address is part of hostname

2001-09-24 Thread gardner


From: [EMAIL PROTECTED]
Operating system: 
PHP version:  4.0.4pl1
PHP Bug Type: Unknown/Other Function
Bug description:  gethostbyname() returns hostname when ip address is part of hostname

When you pass a host name such as
ip-255-255-255-255.reverse.mobilenetics.com to gethostbyname() it returns
the hostname, not the ip address.

Regular hostnames like google.com work.
-- 
Edit bug report at: http://bugs.php.net/?id=13423&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #13422: gethostbyname() returns hostname when ip address is part of hostname

2001-09-24 Thread gardner


From: [EMAIL PROTECTED]
Operating system: Linux 2.2 SMP
PHP version:  4.0.4pl1
PHP Bug Type: Unknown/Other Function
Bug description:  gethostbyname() returns hostname when ip address is part of hostname

When you pass a host name such as
ip-255-255-255-255.reverse.mobilenetics.com to gethostbyname() it returns
the hostname, not the ip address.

Regular hostnames like google.com work.
-- 
Edit bug report at: http://bugs.php.net/?id=13422&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #13421: Problematic MIME-Type "application/x-httpd-php"

2001-09-24 Thread php


From: [EMAIL PROTECTED]
Operating system: Linux
PHP version:  4.0.6
PHP Bug Type: Apache related
Bug description:  Problematic MIME-Type "application/x-httpd-php"

I noticed that using the MIME-Type "application/x-httpd-php" for
php-Scripts produces a problem under Apache 1.3.x with MultiViews turned
on.
When an user agent (like Google or Altavista) sends the Header "Accept:
text/*" and the complete location is not given (e.g.
"http://domain.com/index"; instead of "http://domain.com/index.php";) Apache
tries to guess the right file-name extension. But Apache will answer the
request with a 406 error ("not acceptable") becaus it thinks the php file
is of type "application/x-httpd-php", which is not compatible to
"text/*".
Me suggested solution would be to change the MIME-Type to
"text/x-httpd-php". Content negotiation under Apache 1.3 would work then.

Note: This problem is non existend at Apache 2.0.x where I can change the
MIME type without any problems because php is a filter there.
-- 
Edit bug report at: http://bugs.php.net/?id=13421&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] curl compiler failed

2001-09-24 Thread Stanislav Malyshev


SH>>
SH>> Yes, but it also affects the portability of apps when using cURL,
SH>> you have to worry not only which php version supports which
SH>> features, but also which curl version linked with php supports these
SH>> features, this is a real headache.

No, quite the opposite - if the only thing you have to worry about would
be installed cURL version and not PHP version (or if you could just write
something like requires(curl >= 7.7.2) - just like RPM does, for example)
- it would be easier. Especially taking into account that generally you
hardly know which version of curl which PHP supported - how exactly many
people know which constants were in with PHP 4.0.3/cURL without
looking into the CVSweb? Probably less than two.

That brings us to capabilities discovery and versioning discussion, which
deserves its own topic and serious attention, outside this small issue I
brought up. Maybe someone has to write an RFC for this.

In any case, if you feel that it is absolutely necessary to support this
constant in PHP, even though no cURL release still has it, please insert
the relevant configure check. It is the real pain to go through three
screens of gcc wailings each time and recompile it again just to discover
yet another constant missing. (it would be also pretty much pain to have
latest CVSes of 10+ packages just to be able to compile CVS PHP, but I
talked about this already).
-- 
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED]  http://www.zend.com/ +972-3-6139665 ext.115



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] curl compiler failed

2001-09-24 Thread Sterling Hughes


On Mon, 24 Sep 2001, Stanislav Malyshev wrote:

> SH>> Try latest cvs with one of the curl pre-releases (the latest pre
> SH>> release should work fine).
>
> Maybe it is still possible to ifdef such things? Like, support of two more
> constants is not really so vital for curl usage, and if I have a choice of
> using unpackaged pre-release possibly-buggy version and get into constant
> upgrade circle or stay with checked installed release of curl, I would
> certainly choose the latter.
>

Yes, but it also affects the portability of apps when using cURL,
you have to worry not only which php version supports which
features, but also which curl version linked with php supports these
features, this is a real headache.

-Sterling

>


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] curl compiler failed

2001-09-24 Thread Stanislav Malyshev


SH>> Try latest cvs with one of the curl pre-releases (the latest pre
SH>> release should work fine).

Maybe it is still possible to ifdef such things? Like, support of two more
constants is not really so vital for curl usage, and if I have a choice of
using unpackaged pre-release possibly-buggy version and get into constant
upgrade circle or stay with checked installed release of curl, I would
certainly choose the latter.

-- 
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED]  http://www.zend.com/ +972-3-6139665 ext.115



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] RC3

2001-09-24 Thread Zeev Suraski


If it's a bug fix you believe to be important and the chances, in your 
opinion, of it screwing things up more than it fixes are slim, go ahead and 
commit it...

Zeev

At 14:20 24-09-01, Stig Venaas wrote:
>On Wed, Sep 19, 2001 at 10:05:24PM +0200, Stig Venaas wrote:
> > On Tue, Sep 18, 2001 at 06:13:54PM +0300, Zeev Suraski wrote:
> > > Does anybody still have anything pending for RC3?
> >
> > There seems to be a serious LDAP bug. For instance the following
> > simple script crashes (you should be able to test it):
>
>I never got any feedback on this, what is the right procedure? Do I
>ask you Zeev or anyone else if this can be done, or am I supposed
>myself to commit changes with the right tag? At least I think this
>fix is important, would be nice to get some confirmation that it
>gets in, or reasons for not doing it.
>
>Stig
>
>--
>PHP Quality Assurance Mailing List 
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>To contact the list administrators, e-mail: [EMAIL PROTECTED]


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: class destructors?

2001-09-24 Thread Sebastian Bergmann


[EMAIL PROTECTED] wrote:
> I have been using PHP for a while now, and have wondered why
> it does not support class destructors? It would be a very useful thing.

  http://www.zend.com/engine2/ZendEngine-2.0.pdf

-- 
  Sebastian Bergmann  Measure Traffic & Usability
  http://sebastian-bergmann.de/ http://phpOpenTracker.de/

  Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #13419 Updated: strtok doesn't properly work with "#" as a token

2001-09-24 Thread mfischer


ID: 13419
Updated by: mfischer
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Bogus
Bug Type: Strings related
Operating System: linux 2.4.9 (debian unstable)
PHP Version: 4.0.6.7rc2
New Comment:

This is not a bug. This is the way strtok() works. Although PHP uses its own 
implementation, strtok() under C works the same and PHP mimics the C version (anything 
else would render this function useless).

No bug, bogusifying.

If you need similar functionality take a look at explode()/split()

- Markus

Previous Comments:


[2001-09-24 15:29:53] [EMAIL PROTECTED]

in the following code:
$string = "#This is an example string";
$tok1 = strtok($string,"#");

$tok1 should equal nothing.. however it equals $string

This bug breaks ACID:
http://www.cert.org/kb/acid/

people on IRC have verified that this bug is also in CVS as of this report





Edit this bug report at http://bugs.php.net/?id=13419&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #13418 Updated: versions controvercy

2001-09-24 Thread sander


ID: 13418
Updated by: sander
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Bogus
Bug Type: PHP options/info functions
Operating System: Win2000
PHP Version: 4.0.6
New Comment:

Unable to reproduce. 
Did you update PHP 4.0.5 to 4.0.6? If so, try overwriting all PHP-files (like 
php4ts.dll) in your WINNT\SYSTEM32 directory with new PHP-4.0.6 files. Check your 
httpd.conf for the corrects paths to the php4apache.dll. 
For more information ask on the PHP-INSTALL mailinglist (see 
http://www.php.net/support.php)

Previous Comments:


[2001-09-24 12:50:11] [EMAIL PROTECTED]

Hi,

after installing the windows binary of PHP v.4.0.6 I run phpinfo() and I saw that the 
header was still saying it is 4.0.5. Why am I sure I installed it all correctly? 
Because HTTP_SERVER_VARS["SERVER_SOFTWARE"] says I am running Apache/1.3.14 (Win32) 
PHP/4.0.6 .

And, that seems to me a little bug in phpinfo(), or is it anything abvious on my side?

Thanks,
m





Edit this bug report at http://bugs.php.net/?id=13418&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Fw: Bumping PHP to support 8byteintegers

2001-09-24 Thread Jeroen van Wolffelaar

On Mon, 24 Sep 2001, Sascha Schumann wrote:

> `long long´ support has only become recently adopted by
> compiler vendors.  There are still bugs in common
> implementations like GCC-2 which is why a program which aims
> at portability should not depend on it yet.

I think that IF it is going to be implemented, it should be a compiler
option to choose what the type of integer needs to be: long, long long,
or something else... With proper use of macro's that would mean 1 single
#define.

--Jeroen

Jeroen van Wolffelaar
[EMAIL PROTECTED]
http://www.A-Eskwadraat.nl/~jeroen

--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #13420: open_basedir breaks Apache SSI xbithack

2001-09-24 Thread wbrown


From: [EMAIL PROTECTED]
Operating system: Linux mainserver2 2.4.4
PHP version:  4.0.6
PHP Bug Type: Apache related
Bug description:  open_basedir breaks Apache SSI xbithack

Linux version 2.4.4
Apache version 1.3.19
Php version 4.0.6

When xbithack is set to FULL in .htaccess, setting test.htm chmod to 754
allows the SSI calls in test.htm to perform as expected.

However, when open_basedir is specified in httpd.conf the xbithack
directive is ignored and SSI calls in test.htm stop working.
-- 
Edit bug report at: http://bugs.php.net/?id=13420&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #13419: strtok doesn't properly work with "#" as a token

2001-09-24 Thread curious


From: [EMAIL PROTECTED]
Operating system: linux 2.4.9 (debian unstable)
PHP version:  4.0.6
PHP Bug Type: Strings related
Bug description:  strtok doesn't properly work with "#" as a token

in the following code:
$string = "#This is an example string";
$tok1 = strtok($string,"#");

$tok1 should equal nothing.. however it equals $string

This bug breaks ACID:
http://www.cert.org/kb/acid/

people on IRC have verified that this bug is also in CVS as of this report
-- 
Edit bug report at: http://bugs.php.net/?id=13419&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] curl compiler failed

2001-09-24 Thread Sterling Hughes


On Mon, 24 Sep 2001, Holger Schopohl wrote:

> Hi,
>
> in the current cvs tree:
>
> curl.c: In function `zm_startup_curl':
> curl.c:196: `CURLINFO_SSL_VERIFY_RESULT' undeclared (first use in this
> function)
> curl.c:196: (Each undeclared identifier is reported only once
> curl.c:196: for each function it appears in.)
> curl.c: In function `zif_curl_getinfo':
> curl.c:923: `CURLINFO_SSL_VERIFY_RESULT' undeclared (first use in this
> function)
> make[3]: *** [curl.slo] Error 1
> make[3]: Leaving directory `/usr/src/php4/ext/curl'
> make[2]: *** [all-recursive] Error 1
> make[2]: Leaving directory `/usr/src/php4/ext/curl'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/usr/src/php4/ext'
> make: *** [all-recursive] Error 1
>
> hmm,
>

Try latest cvs with one of the curl pre-releases (the latest pre
release should work fine).

-Sterling


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] class destructors?

2001-09-24 Thread mlwmohawk


Just a thought. I have been using PHP for a while now, and have wondered why
it does not support class destructors? It would be a very useful thing.



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] RE: Bug #13417 Updated: Cannot open file for writing

2001-09-24 Thread Keller, Mathew (ISS Atlanta)


Already did your standard fix, and updated to the latest snap.csv. Nothing
changes and yes I do believe it has something to do with PHP, it works fine
for all other process's.  I followed the do's and dont's Markus, anything
else that you dont want to input.


-Original Message-
From: Bug Database [mailto:[EMAIL PROTECTED]]
Sent: Monday, September 24, 2001 5:59 PM
To: Keller, Mathew (ISS Atlanta)
Subject: Bug #13417 Updated: Cannot open file for writing


ID: 13417
Updated by: mfischer
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Bogus
Bug Type: GD related
Operating System: solaris 8
PHP Version: 4.0.6
New Comment:

Useless bug report and probably a user error.

Please ask support questions at [EMAIL PROTECTED]

Bogusifying. I you really think its a PHP problem first update to the latest
version (try snaps.php.net ) and then reopen this bug report with more
information (read the "do's and dont's")

- Markus

Previous Comments:


[2001-09-24 12:31:22] [EMAIL PROTECTED]

get the following error when trying to create image files (png) with php.

2
Warning
imagepng: unable to open '/images/image1.png' for
writing







ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at
http://bugs.php.net/?id=13417&edit=2

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #13417 Updated: Cannot open file for writing

2001-09-24 Thread mfischer


ID: 13417
Updated by: mfischer
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Bogus
Bug Type: GD related
Operating System: solaris 8
PHP Version: 4.0.6
New Comment:

Useless bug report and probably a user error.

Please ask support questions at [EMAIL PROTECTED]

Bogusifying. I you really think its a PHP problem first update to the latest version 
(try snaps.php.net ) and then reopen this bug report with more information (read the 
"do's and dont's")

- Markus

Previous Comments:


[2001-09-24 12:31:22] [EMAIL PROTECTED]

get the following error when trying to create image files (png) with php.

2
Warning
imagepng: unable to open '/images/image1.png' for writing







Edit this bug report at http://bugs.php.net/?id=13417&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] curl compiler failed

2001-09-24 Thread Derick Rethans


On Mon, 24 Sep 2001, Holger Schopohl wrote:

> and also nl2br() crashes and chunk_split($string,2,' '); doesnt work ...

nl2br() should be fixed can you make sure with the latest CVS, and
make a backtrace of the crash?

Derick


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] curl compiler failed

2001-09-24 Thread Holger Schopohl


Hi,

in the current cvs tree:

curl.c: In function `zm_startup_curl':
curl.c:196: `CURLINFO_SSL_VERIFY_RESULT' undeclared (first use in this 
function)
curl.c:196: (Each undeclared identifier is reported only once
curl.c:196: for each function it appears in.)
curl.c: In function `zif_curl_getinfo':
curl.c:923: `CURLINFO_SSL_VERIFY_RESULT' undeclared (first use in this 
function)
make[3]: *** [curl.slo] Error 1
make[3]: Leaving directory `/usr/src/php4/ext/curl'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/usr/src/php4/ext/curl'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/src/php4/ext'
make: *** [all-recursive] Error 1

hmm,

and also nl2br() crashes and chunk_split($string,2,' '); doesnt work ... 
:-(

Regards,

Holger

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [Zend Engine 2] Re: Undefining user functions/classes at runtime?

2001-09-24 Thread Stig Sæther Bakken


Andrei is writing an extension that does this (explicitly per class).

 - Stig

["Harald Radi" <[EMAIL PROTECTED]>]
> something like the current oo api mechanism would be useful for userland
> too and would possible
> solve markus' problem too.
> 
> if you call a member on an object there could be an __invoke() method
> that handles all calls of
> unknown functions.
> 
> thus $obj->foo("bar");
> 
> will end in $obj->__invoke("foo", "bar");
> 
> if the member foo() doesn't exist.
> 
> -harald.
> 
> > -Original Message-
> > From: Markus Fischer [mailto:[EMAIL PROTECTED]] 
> > Sent: Sunday, September 23, 2001 8:24 PM
> > To: Jeroen van Wolffelaar
> > Cc: PHP Developers Mailing List; [EMAIL PROTECTED]
> > Subject: [Zend Engine 2] Re: Undefining user 
> > functions/classes at runtime?
> > 
> > 
> > On Sun, Sep 23, 2001 at 08:03:59PM +0200, Jeroen van 
> > Wolffelaar wrote : 
> > > > Is it currently possible to undefine user functions or classes at 
> > > > runtime? Although not a newbie ;) I'm unsure if its 
> > possible right 
> > > > now.
> > > 
> > > No, you can't do that in PHP-userland (in the C code it can 
> > be done, 
> > > see implementation of create_function).
> > 
> > > And IMHO that should remain so.
> > > 
> > > > If not, will this be support (ZE2) ?
> > > 
> > > I hope not. Can you give an example where you think it will 
> > be useful?
> > 
> > I'm currently writing an application which is only a dumb 
> > client stub (php-gtk) which receives its code via xml-rpc and 
> > executes it. The problem I have is that I can't refetch the 
> > same code again because I redefinition errors of all kind.
> > 
> > - Markus
> > 

-- 
  Stig Sæther Bakken <[EMAIL PROTECTED]>
  Fast Search & Transfer ASA, Trondheim, Norway

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #13418: versions controvercy

2001-09-24 Thread maxim


From: [EMAIL PROTECTED]
Operating system: Win2000
PHP version:  4.0.6
PHP Bug Type: PHP options/info functions
Bug description:  versions controvercy

Hi,

after installing the windows binary of PHP v.4.0.6 I run phpinfo() and I
saw that the header was still saying it is 4.0.5. Why am I sure I installed
it all correctly? Because HTTP_SERVER_VARS["SERVER_SOFTWARE"] says I am
running Apache/1.3.14 (Win32) PHP/4.0.6 .

And, that seems to me a little bug in phpinfo(), or is it anything abvious
on my side?

Thanks,
m
-- 
Edit bug report at: http://bugs.php.net/?id=13418&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #13416 Updated: Compile errors on make of Apache 1.3.20, PHP & MySLQ Last Version

2001-09-24 Thread derick


ID: 13416
Updated by: derick
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Bogus
Bug Type: MySQL related
Operating System: Slackware 8.0 2.2.19 Kernel
PHP Version: 4.0.6
New Comment:

Already fixed, for 4.0.6, use --with-zlib to your configure line.

Derick

Previous Comments:


[2001-09-24 12:05:25] [EMAIL PROTECTED]

hello,
I don't know if this compile bug is caused by mysql libraries or apache or php. I've 
always used the same configure flags to compile my apache + mysql + php on my others 
linux & freebsd servers and it works fine. Do you know the cause of this error?

Thanx a lot
Bruno Lavoie
[EMAIL PROTECTED]

<=== src/modules/php4
<=== src/modules
gcc -c  -I./os/unix -I./include   -DLINUX=22 -I/root/php-4.0.6 -I/root/php-4.0.6/main 
-I/root/php-4.0.6/main -I
/root/php-4.0.6/Zend -I/root/php-4.0.6/Zend -I/root/php-4.0.6/TSRM 
-I/root/php-4.0.6/TSRM -I/root/php-4.0.6 -DU
SE_EXPAT -I./lib/expat-lite -DNO_DL_NEEDED `./apaci` modules.c
gcc -c  -I./os/unix -I./include   -DLINUX=22 -I/root/php-4.0.6 -I/root/php-4.0.6/main 
-I/root/php-4.0.6/main -I
/root/php-4.0.6/Zend -I/root/php-4.0.6/Zend -I/root/php-4.0.6/TSRM 
-I/root/php-4.0.6/TSRM -I/root/php-4.0.6 -DU
SE_EXPAT -I./lib/expat-lite -DNO_DL_NEEDED `./apaci` buildmark.c
gcc  -DLINUX=22 -I/root/php-4.0.6 -I/root/php-4.0.6/main -I/root/php-4.0.6/main 
-I/root/php-4.0.6/Zend -I/root/
php-4.0.6/Zend -I/root/php-4.0.6/TSRM -I/root/php-4.0.6/TSRM -I/root/php-4.0.6 
-DUSE_EXPAT -I./lib/expat-lite -
DNO_DL_NEEDED `./apaci`\
  -o httpd buildmark.o modules.o modules/standard/libstandard.a 
modules/php4/libphp4.a main/libmain.a ./os/
unix/libos.a ap/libap.a  lib/expat-lite/libexpat.a  -Wl,-rpath,/usr/local/lib 
-Wl,-rpath,/usr/local/mysql/lib
-rdynamic -L/usr/local/lib -L/usr/local/mysql/lib -Lmodules/php4 -L../modules/php4 
-L../../modules/php4 -lmodph
p4  -lc-client  -ldl -lmysqlclient -lcrypt -lresolv -lm -ldl -lnsl  -lresolv   -lm 
-lcrypt
/usr/local/mysql/lib/libmysqlclient.a(my_compress.o): In function `my_uncompress':
my_compress.o(.text+0x9a): undefined reference to `uncompress'
/usr/local/mysql/lib/libmysqlclient.a(my_compress.o): In function `my_compress_alloc':
my_compress.o(.text+0x12a): undefined reference to `compress'
collect2: ld returned 1 exit status
make[2]: *** [target_static] Error 1
make[2]: Leaving directory `/root/apache_1.3.20/src'
make[1]: *** [build-std] Error 2
make[1]: Leaving directory `/root/apache_1.3.20'
make: *** [build] Error 2





Edit this bug report at http://bugs.php.net/?id=13416&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #13415 Updated: Compile Time Error

2001-09-24 Thread gdunne


ID: 13415
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Compile Failure
Operating System: Linux 2.0.34
PHP Version: 4.0.6
New Comment:

I went into filestat.c and changed the function to this, I won't be able to use this 
function now, but everything compiled and ran smoothly...


PHP_FUNCTION(diskfreespace)
{
double bytesfree = 0;
RETURN_DOUBLE(bytesfree);
}

Previous Comments:


[2001-09-24 12:25:12] [EMAIL PROTECTED]

Slackware, not positive on the version #, but the kernel is 2.0.34



[2001-09-24 11:48:22] [EMAIL PROTECTED]


 i guess it's due to the rather old kernel?

 can you tell us what distribution (vendor and version)
 you are using?



[2001-09-24 11:41:39] [EMAIL PROTECTED]

Configuration Line - 
./configure --with-mysql --with-gd=/usr/local --enable-track-vars 
--with-apxs=/usr/local/apache
-1.3.20/bin/apxs

Apache Version - 1.3.20

Reported Error:
filestat.c: In function `php_if_diskfreespace':
filestat.c:157: storage size of `buf' isn't known
make[3]: *** [filestat.lo] Error 1





Edit this bug report at http://bugs.php.net/?id=13415&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #13417: Cannot open file for writing

2001-09-24 Thread mkeller


From: [EMAIL PROTECTED]
Operating system: solaris 8
PHP version:  4.0.6
PHP Bug Type: GD related
Bug description:  Cannot open file for writing

get the following error when trying to create image files (png) with php.

2
Warning
imagepng: unable to open '/images/image1.png' for
writing


-- 
Edit bug report at: http://bugs.php.net/?id=13417&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #13415 Updated: Compile Time Error

2001-09-24 Thread gdunne


ID: 13415
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Open
Bug Type: Compile Failure
Operating System: Linux 2.0.34
PHP Version: 4.0.6
New Comment:

Slackware, not positive on the version #, but the kernel is 2.0.34

Previous Comments:


[2001-09-24 11:48:22] [EMAIL PROTECTED]


 i guess it's due to the rather old kernel?

 can you tell us what distribution (vendor and version)
 you are using?



[2001-09-24 11:41:39] [EMAIL PROTECTED]

Configuration Line - 
./configure --with-mysql --with-gd=/usr/local --enable-track-vars 
--with-apxs=/usr/local/apache
-1.3.20/bin/apxs

Apache Version - 1.3.20

Reported Error:
filestat.c: In function `php_if_diskfreespace':
filestat.c:157: storage size of `buf' isn't known
make[3]: *** [filestat.lo] Error 1





Edit this bug report at http://bugs.php.net/?id=13415&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] New Extension

2001-09-24 Thread Markus Fischer


On Mon, Sep 24, 2001 at 10:54:51AM -0500, Ben Menking wrote : 
> I wrote an extension over the weekend that will authenticate users to a m$
> windows domain server.  Does this functionality already exist in PHP4?  If
> not I'd love to include it.

To my knowledge there are already two existing (not included in
php4 however) extensions. Just post a url so we can look at it.

Two question about it:

1) Does it use smbval or not?
2) Is it portable (unix/win32)?

I've finished such an extension too but the underlying smbval
library is way out of date and imposes possible security holes
(which, when writting carefully, can be crossed out) but isn't
really portable (I stopped trying to get the beast compile under
win32 itself).

- Markus

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #13416: Compile errors on make of Apache 1.3.20, PHP & MySLQ Last Version

2001-09-24 Thread zonzon


From: [EMAIL PROTECTED]
Operating system: Slackware 8.0 2.2.19 Kernel
PHP version:  4.0.6
PHP Bug Type: MySQL related
Bug description:  Compile errors on make of Apache 1.3.20, PHP & MySLQ Last Version

hello,
I don't know if this compile bug is caused by mysql libraries or apache or
php. I've always used the same configure flags to compile my apache + mysql
+ php on my others linux & freebsd servers and it works fine. Do you know
the cause of this error?

Thanx a lot
Bruno Lavoie
[EMAIL PROTECTED]

<=== src/modules/php4
<=== src/modules
gcc -c  -I./os/unix -I./include   -DLINUX=22 -I/root/php-4.0.6
-I/root/php-4.0.6/main -I/root/php-4.0.6/main -I
/root/php-4.0.6/Zend -I/root/php-4.0.6/Zend -I/root/php-4.0.6/TSRM
-I/root/php-4.0.6/TSRM -I/root/php-4.0.6 -DU
SE_EXPAT -I./lib/expat-lite -DNO_DL_NEEDED `./apaci` modules.c
gcc -c  -I./os/unix -I./include   -DLINUX=22 -I/root/php-4.0.6
-I/root/php-4.0.6/main -I/root/php-4.0.6/main -I
/root/php-4.0.6/Zend -I/root/php-4.0.6/Zend -I/root/php-4.0.6/TSRM
-I/root/php-4.0.6/TSRM -I/root/php-4.0.6 -DU
SE_EXPAT -I./lib/expat-lite -DNO_DL_NEEDED `./apaci` buildmark.c
gcc  -DLINUX=22 -I/root/php-4.0.6 -I/root/php-4.0.6/main
-I/root/php-4.0.6/main -I/root/php-4.0.6/Zend -I/root/
php-4.0.6/Zend -I/root/php-4.0.6/TSRM -I/root/php-4.0.6/TSRM
-I/root/php-4.0.6 -DUSE_EXPAT -I./lib/expat-lite -
DNO_DL_NEEDED `./apaci`\
  -o httpd buildmark.o modules.o modules/standard/libstandard.a
modules/php4/libphp4.a main/libmain.a ./os/
unix/libos.a ap/libap.a  lib/expat-lite/libexpat.a 
-Wl,-rpath,/usr/local/lib -Wl,-rpath,/usr/local/mysql/lib
-rdynamic -L/usr/local/lib -L/usr/local/mysql/lib -Lmodules/php4
-L../modules/php4 -L../../modules/php4 -lmodph
p4  -lc-client  -ldl -lmysqlclient -lcrypt -lresolv -lm -ldl -lnsl 
-lresolv   -lm -lcrypt
/usr/local/mysql/lib/libmysqlclient.a(my_compress.o): In function
`my_uncompress':
my_compress.o(.text+0x9a): undefined reference to `uncompress'
/usr/local/mysql/lib/libmysqlclient.a(my_compress.o): In function
`my_compress_alloc':
my_compress.o(.text+0x12a): undefined reference to `compress'
collect2: ld returned 1 exit status
make[2]: *** [target_static] Error 1
make[2]: Leaving directory `/root/apache_1.3.20/src'
make[1]: *** [build-std] Error 2
make[1]: Leaving directory `/root/apache_1.3.20'
make: *** [build] Error 2
-- 
Edit bug report at: http://bugs.php.net/?id=13416&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] [RFC] Versioning rules for PHP/Zend/PEAR/Extensions

2001-09-24 Thread Andrei Zmievski


On Mon, 24 Sep 2001, Jani Taskinen wrote:
> 2. General rules for PHP, Zend and PEAR/C-extensions
> 
> 
>   v.m.b (e.g. 4.0.8)
> 
>   v = Functions removed, function behaviour changed, API changes,
>   major parts rewritten. (BC might be broken)
>   m = New functionality added. Only backwards compatible API changes. (100% BC)
>   b = Bug fixes. No new functions added. No API changes. (100% BC)
>   Left out if zero (0).

It's going to be pretty tough to not add any functionality while also
fixing bugs. Maybe 'b' could be incremented for bug fixes and minor
functionality enhancements and 'm' for more extensive new functionality
and API changes?

> 3. Stable/development branches [OPTIONAL]
> --
> 
>   Even minor number: stable (x.2.x) branch.
>   Odd minor number : development (x.3.x) branch.
> 
>   (this is not needed for PHP. Our stable branch can be the
>release branch and the development branch is just the HEAD)

Correct.

> 5. New PHP/Zend API function version_compare()
> --
> 
>   proto int version_compare(string version1, string version2 [, string operator])
> 
>   This function knows this: 4.0.5 < 4.0.6RC2 < 4.1.4 < 4.2-RC1
>   and returns:
> 
>   -1  version1  <  version2
>0  version1 === version2
>1  version1  >  version2

We already have such versions, they are called strnatcmp() and
natsort().

>   Extensions can use the same function internally to check the Zend / PHP
>   versions.

How do we check PEAR versions, will PEAR class have a standard function
that returns version?

-Andrei

"The day Microsoft makes something that doesn't suck, 
is probably the day Microsoft starts making vacuum cleaners."
- Ernst Jan Plugge

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] New Extension

2001-09-24 Thread Ben Menking


I wrote an extension over the weekend that will authenticate users to a m$
windows domain server.  Does this functionality already exist in PHP4?  If
not I'd love to include it.


-- 
Ben Menking
<[EMAIL PROTECTED]>
http://www.menking.net/


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: Bug #13415 Updated: Compile Time Error

2001-09-24 Thread Gavin B. Dunne


Linux Slackware not exactly sure what version # it is, probably 7
something...




> ID: 13415
> Updated by: hholzgra
> Reported By: [EMAIL PROTECTED]
> Old Status: Open
> Status: Feedback
> Bug Type: Compile Failure
> Operating System: Linux 2.0.34
> PHP Version: 4.0.6
> New Comment:
>
>
>  i guess it's due to the rather old kernel?
>
>  can you tell us what distribution (vendor and version)
>  you are using?
>
> Previous Comments:
> 
>
> [2001-09-24 11:41:39] [EMAIL PROTECTED]
>
> Configuration Line -
>
./configure --with-mysql --with-gd=/usr/local --enable-track-vars --with-apx
s=/usr/local/apache
> -1.3.20/bin/apxs
>
> Apache Version - 1.3.20
>
> Reported Error:
> filestat.c: In function `php_if_diskfreespace':
> filestat.c:157: storage size of `buf' isn't known
> make[3]: *** [filestat.lo] Error 1
>
> 
>
>
>
> ATTENTION! Do NOT reply to this email!
> To reply, use the web interface found at
http://bugs.php.net/?id=13415&edit=2
>
>



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #13415 Updated: Compile Time Error

2001-09-24 Thread hholzgra


ID: 13415
Updated by: hholzgra
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Feedback
Bug Type: Compile Failure
Operating System: Linux 2.0.34
PHP Version: 4.0.6
New Comment:


 i guess it's due to the rather old kernel?

 can you tell us what distribution (vendor and version)
 you are using?

Previous Comments:


[2001-09-24 11:41:39] [EMAIL PROTECTED]

Configuration Line - 
./configure --with-mysql --with-gd=/usr/local --enable-track-vars 
--with-apxs=/usr/local/apache
-1.3.20/bin/apxs

Apache Version - 1.3.20

Reported Error:
filestat.c: In function `php_if_diskfreespace':
filestat.c:157: storage size of `buf' isn't known
make[3]: *** [filestat.lo] Error 1





Edit this bug report at http://bugs.php.net/?id=13415&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #13415: Compile Time Error

2001-09-24 Thread gdunne


From: [EMAIL PROTECTED]
Operating system: 
PHP version:  4.0.6
PHP Bug Type: Compile Failure
Bug description:  Compile Time Error

Configuration Line - 
./configure --with-mysql --with-gd=/usr/local --enable-track-vars
--with-apxs=/usr/local/apache
-1.3.20/bin/apxs

Apache Version - 1.3.20

Reported Error:
filestat.c: In function `php_if_diskfreespace':
filestat.c:157: storage size of `buf' isn't known
make[3]: *** [filestat.lo] Error 1
-- 
Edit bug report at: http://bugs.php.net/?id=13415&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] CVSup - connection refused

2001-09-24 Thread Stefan Esser


Hi,

I am trying for several weeks to mirror the CVS Repository via CVSup, but i
permanently get a
"connection refused" error. Is there no longer a CVSup server or is there
just a temporary problem?

thanks,
stefan esser


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #12444: require_once doesn't support relative paths completely

2001-09-24 Thread Urs Hürlimann


we've got the same error on linux/php4.04 with ZendServerSuite and the
Zend_IDE(w2k).

is there any solution to this bug?
thanks,
urs hürlimann

www.mondaycoffee.com

mondaycoffee ag
soodstrasse 55
postfach 2110
8134 adliswil 2
direktwahl 01.712.30.74
fax 01.712.30.71

--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] RE: Bug #11879 Updated: error al ejecuta make

2001-09-24 Thread Galindo Cruz Guillermo


???help please...

> -Mensaje original-
> De:   Bug Database [SMTP:[EMAIL PROTECTED]]
> Enviado el:   Domingo 23 de Septiembre de 2001 4:47 PM
> Para: [EMAIL PROTECTED]
> Asunto:   Bug #11879 Updated: error al ejecuta make
> 
> ID: 11879
> Updated by: jimw
> Reported By: [EMAIL PROTECTED]
> Old Status: 
> Status: Assigned
> Bug Type: Compile Failure
> Operating System: NCR WM 4300 unix systema V MP-RA
> PHP Version: 4.0.6
> Old Assigned To: 
> Assigned To: derick
> New Comment:
> 
> fixing status that was not set.
> 
> Previous Comments:
> 
> 
> [2001-07-13 11:53:52] [EMAIL PROTECTED]
> 
> i send the files to e-mail [EMAIL PROTECTED] is ok
> 
> thanks's
> 
> 
> 
> [2001-07-05 10:16:33] [EMAIL PROTECTED]
> 
> true... can you put them up in a gzip file on a website?
> 
> Derick
> 
> 
> 
> [2001-07-05 10:08:29] [EMAIL PROTECTED]
> 
> how Can i add my main/php_config.h, config.log, config.debug into this
> bugreport
> what is your e-mail
> the file's is very long 
> the number lines for files
>1981  ./main/php_config.h
> 494  ./config.log
> the file config.debug not exist, 
>  only file config* are this
> config.cache
> config.guess
> config.log
> config.nice
> config.status
> config.sub
> config_vars.mk
> configure
> configure.in
> 
> thanks...
> 
> 
> 
> [2001-07-04 13:24:02] [EMAIL PROTECTED]
> 
> It seems that PHP/autoconf/automake is not very compatible with the NCR
> system.
> Can you add your main/php_config.h, config.log, config.debug into this
> bugreport, or place them on some URL?
> 
> Derick
> 
> 
> 
> [2001-07-04 10:45:11] [EMAIL PROTECTED]
> 
> 1.-
> $./configure --with-informix=yes
> --with-apache=/admvos/apache/apache_1.3.19 --enable-sysvsem 
> --enable-sysvshm --without-mysql --enable-track-vars   
> # ok no error
> 2.-
> $make# last's lines
> cc  -I. -I/admvos/sistgczo/php-4.0.6/ext/posix
> -I/admvos/sistgczo/php-4.0.6/main
> -I/admvos/sistgczo/php-4.0.6/admvos/apache/apache_1.3.19/src/include
> -I/admvos/apache/apache_1.3.19/src/os/unix
> -I/admvos/sistgczo/php-4.0.6/Zend/usr/informix/incl/esql
> -I/admvos/sistgczo/php-4.0.6/ext/xml/expat/xmltok
> -I/admvos/sistgczo/php-4.0.6/ext/xml/expat/xparse
> -I/admvos/sistgczo/php-4.0.6/TSRM  -DSUPPORT_UTF8 -DXML_BYTE_ORDER=12   -c
> posix.c && touch posix.lo
> NCR High Performance C Compiler R3.0c
> (c) Copyright 1994-97, NCR Corporation
> (c) Copyright 1987-97, MetaWare Incorporated
> w "/admvos/sistgczo/php-4.0.6/Zend/zend_execute.h",L185/C5(#257):
> '=' encountered where '==' may have been intend.
> w "/admvos/sistgczo/php-4.0.6/Zend/zend_execute.h",L198/C4(#257):
> '=' encountered where '==' may have been intend.
> w "/admvos/sistgczo/php-4.0.6/ext/standard/php_string.h",L125/C5(#257):
> '=' encountered where '==' may have been intend.
> E "posix.c",L357/C17(#237): NGROUPS_MAX: Identifier is undeclared.
> E "posix.c",L357/C9(#445):  gidlist
> |Type of variable is an array of zero length.
> E "posix.c",L361/C21(#237): NGROUPS_MAX: Identifier is undeclared.
> w (#657):   (info) How referenced files were included:
> |File /admvos/sistgczo/php-4.0.6/Zend/zend_execute.h from
> /admvos/sistgczo/php-4.0.6/Zend/zend_API.h from
> /admvos/stgczo/php-4.0.6/main/php.h from posix.c.
> |File /admvos/sistgczo/php-4.0.6/ext/standard/php_string.h from
> posix.c.
> 3 user errors   4 warnings
> *** Error code 3 (bu21)
> 
> make: fatal error.
> *** Error code 1 (bu21)
> 
> make: fatal error.
> *** Error code 1 (bu21)
> 
> make: fatal error.
> *** Error code 1 (bu21)
> 
> make: fatal error.
> $
> TAHNKS
> 
> 
> 
> 
> 
> 
> ATTENTION! Do NOT reply to this email!
> To reply, use the web interface found at
> http://bugs.php.net/?id=11879&edit=2
> 
> 

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #13414: Include not being included

2001-09-24 Thread mail


From: [EMAIL PROTECTED]
Operating system: Windows 2000 Advanced Server
PHP version:  4.0.6
PHP Bug Type: Scripting Engine problem
Bug description:  Include not being included

I keep running into the same problem with every include I try to process. 
I tried modifying the php.ini file but it still does not work.  The same
site worked fine on the old version of PHP.

Fatal error: Failed opening required 'conf.php' 
(include_path='') in C:\inetpub\wwwroot\cp\webmail\index.php on line 12


Also, why do I need to list a specific path in the php.ini file when I want
to be able to include files from a range of different directories?  We host
multiple websites and would like to be able to use PHP but he directories
will not be shared.

Thanks,
Craig
Vdomains.com
-- 
Edit bug report at: http://bugs.php.net/?id=13414&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Fw: Bumping PHP to support 8byteintegers

2001-09-24 Thread Sascha Schumann


> I didn't plan to implement it myself... yikes indeed. The question was
> wether all compilers on 32bit platforms DO have long long support at
> all, in other words: is it true that all compilers for which PHP needs
> to compile have a C-type which is 64bit (native or not)?

`long long´ support has only become recently adopted by
compiler vendors.  There are still bugs in common
implementations like GCC-2 which is why a program which aims
at portability should not depend on it yet.

- Sascha Experience IRCG
  http://schumann.cx/http://schumann.cx/ircg


--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV]Fw: Bumping PHP to support 8byte integers

2001-09-24 Thread Jeroen van Wolffelaar


On Mon, 24 Sep 2001, Markus Fischer wrote:

> Hm. You go and figure out and tell us all. :-)
>
> Btw, macros should _always_ be used. There is no no ever never a
> reason not to do so.
>
> *waiting for the patch* ;-)

Ithink i'm going to try wether it works, and i'll commit my huge
find&replace for the macro's... Unsubscribe from php-cvs while you still
can ;-)
(just kidding... I hope)

Jeroen

>
> - Markus
>
> On Mon, Sep 24, 2001 at 09:13:35AM +0200, Jeroen van Wolffelaar wrote :
> > On Sun, 23 Sep 2001 [EMAIL PROTECTED] wrote:
> > > Hey, it's open source, go for it dude. Let us know.
> >
> > :-)
> >
> > I at least wanted to hear wether there are some principial contra's
> > against this, because it would be a waste of time if it turned out that
> > one wouldn't ever think of implementing this. And I didn't know wether
> > this has been thought over before.
> > A major point is of course that it would probably break ALL extensions,
> > unless they use Z_LVAL() macro's all the time in stead of
> > zval.value.lval...
> >
> > I'll see wether I can get it more or less running without too much
> > work... My estimate is that the performance inpact will be not more than
> > a few percents, probably lower. But it's an estimate!
> >
> > > On the 32bit environments, 64bit integers are implemented as long long,
> > > unless you want to implement the 64bit manipulation routines yourself
> > > (yikes.)
> >
> > I didn't plan to implement it myself... yikes indeed. The question was
> > wether all compilers on 32bit platforms DO have long long support at
> > all, in other words: is it true that all compilers for which PHP needs
> > to compile have a C-type which is 64bit (native or not)?
> >
> > --Jeroen
> >
> > Jeroen van Wolffelaar
> > [EMAIL PROTECTED]
> > http://www.A-Eskwadraat.nl/~jeroen
> >
> >
> > --
> > PHP Development Mailing List 
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> > To contact the list administrators, e-mail: [EMAIL PROTECTED]
>
>

Jeroen van Wolffelaar
[EMAIL PROTECTED]
http://www.A-Eskwadraat.nl/~jeroen


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] RC3

2001-09-24 Thread Stig Venaas

On Wed, Sep 19, 2001 at 10:05:24PM +0200, Stig Venaas wrote:
> On Tue, Sep 18, 2001 at 06:13:54PM +0300, Zeev Suraski wrote:
> > Does anybody still have anything pending for RC3?
> 
> There seems to be a serious LDAP bug. For instance the following
> simple script crashes (you should be able to test it):

I never got any feedback on this, what is the right procedure? Do I
ask you Zeev or anyone else if this can be done, or am I supposed
myself to commit changes with the right tag? At least I think this
fix is important, would be nice to get some confirmation that it
gets in, or reasons for not doing it.

Stig

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Fw: Bumping PHP to support 8byte integers

2001-09-24 Thread Markus Fischer


Hm. You go and figure out and tell us all. :-)

Btw, macros should _always_ be used. There is no no ever never a
reason not to do so.

*waiting for the patch* ;-)

- Markus

On Mon, Sep 24, 2001 at 09:13:35AM +0200, Jeroen van Wolffelaar wrote : 
> On Sun, 23 Sep 2001 [EMAIL PROTECTED] wrote:
> > Hey, it's open source, go for it dude. Let us know.
> 
> :-)
> 
> I at least wanted to hear wether there are some principial contra's
> against this, because it would be a waste of time if it turned out that
> one wouldn't ever think of implementing this. And I didn't know wether
> this has been thought over before.
> A major point is of course that it would probably break ALL extensions,
> unless they use Z_LVAL() macro's all the time in stead of
> zval.value.lval...
> 
> I'll see wether I can get it more or less running without too much
> work... My estimate is that the performance inpact will be not more than
> a few percents, probably lower. But it's an estimate!
> 
> > On the 32bit environments, 64bit integers are implemented as long long,
> > unless you want to implement the 64bit manipulation routines yourself
> > (yikes.)
> 
> I didn't plan to implement it myself... yikes indeed. The question was
> wether all compilers on 32bit platforms DO have long long support at
> all, in other words: is it true that all compilers for which PHP needs
> to compile have a C-type which is 64bit (native or not)?
> 
> --Jeroen
> 
> Jeroen van Wolffelaar
> [EMAIL PROTECTED]
> http://www.A-Eskwadraat.nl/~jeroen
> 
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]

-- 
Markus Fischer,  http://guru.josefine.at/~mfischer/
EMail: [EMAIL PROTECTED]
PGP Public  Key: http://guru.josefine.at/~mfischer/C2272BD0.asc
PGP Fingerprint: D3B0 DD4F E12B F911 3CE1  C2B5 D674 B445 C227 2BD0
  -All your scripts are belong to Zend-

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #13134 Updated: ftp_put couldn't open local file

2001-09-24 Thread mfischer


ID: 13134
Updated by: mfischer
Reported By: [EMAIL PROTECTED]
Old Status: Closed
Status: Bogus
Bug Type: FTP related
Operating System: windows NT
PHP Version: 4.0.5
New Comment:

User error -> bogusifying.

- Markus

Previous Comments:


[2001-09-24 03:31:24] [EMAIL PROTECTED]

Sorries,

1-Sorry, It was a human error (ok, i'm this human), my distant path was wrong
2-Sorry for the response time, i was go away on holiday.
Thanks for your interest
John 



[2001-09-22 11:59:01] [EMAIL PROTECTED]

No feedback, so closing

Derick



[2001-09-04 12:07:43] [EMAIL PROTECTED]

Can you provide a sample script?



[2001-09-04 11:30:49] [EMAIL PROTECTED]

ftp_put couldn't open local file to transfert on remote





Edit this bug report at http://bugs.php.net/?id=13134&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] cURL does not compile

2001-09-24 Thread Stanislav Malyshev


cURL from CVS does not compile with cURL 7.8. I guess it's because of
using new options, etc. Can it be made so that cURL module does not
require constant upgrading to latest CVS of cURL?
Like, some ifdefs, etc.? Or, if this is impossible, is it possible to
update configure also so it would warn that installed cURL is not enough
anymore?

-- 
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED]  http://www.zend.com/ +972-3-6139665 ext.115



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #13413: Seg Fault when urlencoding a binary string

2001-09-24 Thread php


From: [EMAIL PROTECTED]
Operating system: Linux 2.4
PHP version:  4.0.6
PHP Bug Type: URL related
Bug description:  Seg Fault when urlencoding a binary string

If we pass a binary string which contains a byte with
an ASCII value of "0" to urlencode, then PHP will segfault.

This short script will demonstrate the problem.  Notice
that I am using urldecode because I have no way
of printing an ascii value of 0.



I believe the problem is in file ../ext/standard/url.c
and in function php_url_encode().  This function uses
allocates memory for the new string after determining
the length of the input string via strlen(). However, a 
binary string could contain a byte with a value of zero, 
thereby yielding a shorter string length and not enough
memory allocated.

I'll also include a suggested patch below.

--- ext/standard/url.c.orig Mon Sep 24 02:53:54 2001
+++ ext/standard/url.c  Mon Sep 24 02:53:38 2001
@@ -239,7 +239,7 @@
 {
register int x, y;
unsigned char *str;
-   str = (unsigned char *) emalloc(3 * strlen(s) + 1);
+   str = (unsigned char *) emalloc(3 * len + 1);
for (x = 0, y = 0; len--; x++, y++) {
str[y] = (unsigned char) s[x];
if (str[y] == ' ') {





P.S. Thanks for working on PHP, it's a fantastic language
and I appreciate your effort.

-Manuel

-- 
Edit bug report at: http://bugs.php.net/?id=13413&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] enable truetype string function in gd

2001-09-24 Thread Thomas Wentzel


Okay!

Apparently I have to supply the full path when using imagettfbbox and 
imagettftext - This definitely changed from gd-1.8.x to gd-2.x - might
be 
a good idea to add this to the documentation???
But still - There's still an issue about the imageftbbox and imagefttext
functions...

Thomas


Thomas Wentzel wrote:
> 
> I realized that just after posting my question... Though solving my
> configure problem I still can't get freetype to work...
> I had everything running under php-4.0.4 (including gd and freetype 1.x)
> However due to the patent issues it is necessary for me to use freetype2
> which isn't too bad in itself ;)
> Well...
> I saw an "old" submission from Wez claiming that the problems I were
> experiencing wasn't a PHP problem, but rather a gd problem. I tried out
> the little C program he included and true enough - The problem was, that
> gd for some reason didn't include TrueType support (allthough everything
> suggested that it ought to)... Well after searching high and low - I
> found
> this excellent :) link, http://www.alt-php-faq.org/local/68/ , which
> says
> that gd-1.8.x doesn't support freetype2 - and how to successfully
> compile
> gd and freetype into PHP. I realize that this has little to do as such
> with
> the forum of this mailing list, but I also believe, that many get their
> first
> experience with gd end freetype when trying to compile it into php,
> which sort
> of justifies my entry ;)
> Ho hum... Now I have everything up and running - or so it would seem,
> but when
> I try to utilize the imagettfbbox og imagettftext functions I get an
> error saying
> "Could not find/open font". In light of the troubles with gd and
> freetype - it would
> seem likely that this problem also stems from that and not PHP - but I'm
> asking here
> anyway - because it seems that this forum is much more active than the
> various gd and
> freetype forums.
> Another thing... I ran through the ext/gd sources and found some
> functions (not included
> in the manual pages) namely imageftbbox and imagefttext, but whenever I
> try to use these
> functions I get an error saying that freetype2 support wasn't included
> in the PHP build (??)
> Can anybody shed some light on this?
> 
> Thomas
> 
> Rasmus Lerdorf wrote:
> >
> > > I try to get the above mentioned to work with the 4.0.6 release on
> > > Linux!
> > >
> > > But even though I provide the configure script with the
> > > --enable-gd-native-ttf
> > > switch, it reports that the feature is a no go
> >
> > There was a slight buglet in 4.0.6.  Use
> >
> >   --enable-gd-native-tt
> >
> > instead.
> >
> > -Rasmus
> >
> > --
> > PHP Development Mailing List 
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> > To contact the list administrators, e-mail: [EMAIL PROTECTED]
> 
> --
> PHP Development Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

2001-09-24 Thread 91online


×ð¾´µÄÅ®Ê¿/ÏÈÉú£º
ÇëÄúÔÚ°ÙÃ¦Ö®ÖÐ£¬¿´Ò»ÏÂ´Ë·âÐÅ£¬»¶ÓºÏ×÷,¹²Í¬·¢Õ¹£¡
¾ÍÒµÔÚÏßÍøÕ¾ÊÇÒ»¼Ò¹«ÒæÐÔ¡¢Ìá¹©Ãâ·Ñ·þÎñµÄ×¨ÒµÐÔÍøÕ¾£¬ÏÖ´ÓÊÂÓÚ£¬Ê§ÒµÕßµÄÐÄÌ¬·ÖÎö¡¢ÇóÖ°¹ÛÄîµÄ¸üÐÂÌ½ÌÖ¡¢ÇóÖ°µÄ·½·¨½éÉÜ¡¢ÀÍ¶¯¼°´´ÒµÕþ²ß·¨¹æ×ÉÑ¯¡¢½ÌÓý»òÖ°Òµ¼¼ÄÜÕÐÉúÅàÑµÐÅÏ¢¡¢ÆóÒµÕÐ¹¤ÕÐÆ¸ÐÅÏ¢(°üÀ¨ÈË²Å½»Á÷ÊÐ³¡ÐÅÏ¢£©¡¢ÖÂ¸»½ðµã×Ó¼°ÐÂ¼¼Êõ·¢²¼¡¢Ñ°Çó´´ÒµÖÂ¸»ºÏ×÷ÕßÐÅÏ¢·¢²¼µÈµÈ¡£

ÎªÊ¹¡°¾ÍÒµÔÚÏß¡±ÕæÕýÄÜ³ÉÎª¾ÍÒµÕßÖªÐÄÈË£¬´ïµ½¾ÍÒµ¡¢ÖÂ¸»Ä¿µÄ£¬ÍøÕ¾ÓÐÏÂÁÐÆµµÀÊÇÃâ·ÑµÄ¡£
-
¡ôÃâ·ÑÎªÓÃÈËµ¥Î»¿¯µÇÕÐ¹¤ÕÐÆ¸ÐÅÏ¢£¨°üÀ¨ÈË²Å½»Á÷ÊÐ³¡ÐÅÏ¢£©
¡ôÃâ·ÑÎª½ÌÓý»òÖ°Òµ¼¼ÄÜÅàÑµµ¥Î»¿¯µÇÕÐÉúÅàÑµÐÅÏ¢
¡ôÃâ·ÑÎª³ö°æÉç»òÍ¼ÊéÉÌÍÆ¼öºÃµÄÖ°Òµ¼¼ÄÜÅàÑµÊé¼®¼°ÖÂ¸»¼¼ÊõÊé¼®
¡ôÃâ·ÑÎªÇóÖ°ÈËÔ±¿¯µÇÇóÖ°¼òÀú¼°¸öÈËÇóÖ°ÔÚÏßµÇ¼Ç
--
ÎªÁËÌá³«¾ÍÒµÐÂ¿®Äî£¬ÍØ¿í¾ÍÒµÇþµÀ£º
¡ôÃâ·ÑÎªÆóÒµ·¢²¼Ñ°Çó´´ÒµÖÂ¸»ºÏ×÷Õß¼°Ñ°Çó´úÀíÉÌÐÅÏ¢
¡ôÃâ·ÑÎª¼¼Êõ×ªÈÃµ¥Î»ÍÆ¹ãÖÂ¸»ºÃµã×ÓºÃ¼¼Êõ
--
ÍøÉÏÒôÀÖ²è×ùÆµµÀ£º
¡ôÒ²Ãâ·ÑÎª¸÷µØ·½ÌØ²úµÄÃû²èÒûÁÏ¾ÆÀà×öÐû´«½éÉÜ
--
¹ã¸æ¿¯µÇ²Ù×÷·½·¨£º
¡ñÇóÖ°ÈËÔ±Ðè¿¯µÇ¸öÈËÇóÖ°¼òÀú£¬Ö±½Ó°Ñ¼òÀúÒÔµç×ÓÎÄµµ×ÊÁÏÍ¶Èë±¾ÍøÕ¾E-mail¡££¨ÎðÓÃ¸½¼þÐÎÊ½£©,²¢×¢Ã÷ÓûÇóÖ°ÒµÖÖÀà¡£
¡ñÆäËü¹ã¸æ²Ù×÷°ì·¨(1)°Ñ¹ã¸æÐÅÏ¢ÎÄ×Ö²ÄÁÏµÄµç×ÓÎÄµµÍ¶Èë±¾ÍøÕ¾E-mailÐÅÏä£¬¹ã¸æÄÚÈÝÓ¦È«ÃæÇå³þ£¬Óï¾äÒª¼ò½àÃ÷ÁË£¬¾ßÌåÑù£¨¸ñ£©Ê½¿Éä¯ÀÀÏà¹ØÆµµÀµÄÄÚÈÝ¡£(2)¾¡¿ÉÄÜµØ°Ñ¹ã¸æÐÅÏ¢ÎÄ×Ö²ÄÁÏ´òÓ¡³ÉÊéÃæÎÄµµ²¢¼Ó¸Çµ¥Î»¹«ÕÂ¡¢¸öÈË¹ã¸æ¾¡¿ÉÄÜÌá¹©¹ã¸æÕæÊµÐÔÖ¤¾Ý²ÄÁÏ£¬ÓÊ¼Äµ½±¾ÍøÕ¾¡££¨3£©±¾ÍøÕ¾ÔÚÊÕµ½µç×ÓÎÄµµ×ÊÁÏºÍ´òÓ¡µÄÊéÃæÎÄµµ×ÊÁÏºó£¬12Ð¡Ê±ÄÚÓèÒÔ·¢²¼¡£
¡ñ±¾ÍøÕ¾½ö¸øÓèÓÐÒæÉç»á½¡¿µ·¢Õ¹¡¢ºëÑïÉç»áÕýÆø¡¢·ûºÏ¹ú¼Ò·¨ÂÉ·¨¹æ¡¢·ûºÏÉç»á¹«µÂµÄ¹ã¸æÐÅÏ¢Ìá¹©Ãâ·Ñ¿¯µÇ»ú»á£¬ÒÑ¿¯µÇµÄ¹ã¸æÐÅÏ¢½âÊÍÈ¨¼°È«²¿ÔðÈÎÒåÎñÓÉ¿¯µÇµ¥Î»¸ºÔð¡£
--
   
ÍøÕ¾´Ó½ñÄêÔªÔÂ·ÝÍÆ³öÉÏÊöÃâ·Ñ·þÎñÒµÎñÖÁ½ñ£¬ÒÑ³É¹¦µØÎªÊý°Ù¼Òµ¥Î»Ãâ·Ñ¿¯µÇÁËÕÐÆ¸¡¢½ÌÓýÅàÑµ¡¢ÖÂ¸»½ðµã×Ó£¨·½·¨£©¡¢¼¼Êõ×ªÈÃ¡¢Ñ°Çó¼ÓÃËºÏ×÷µÈ¹ã¸æÐÅÏ¢¡£Í¨¹ý¶ÔÒÑ¿¯µÇ¹ã¸æ²¿·Öµ¥Î»½øÐÐµÄÐÅº¯»Ø·Ã½á¹û£¬Ò»Ð©µ¥Î»ÒÑÈ¡µÃÁËÒ»¶¨µÄ¾¼ÃÐ§ÒæºÍÉç»áÐ§Òæ¡£¸ü¿ÉÏ²µÄÊÇ£¬ÍøÕ¾ÈÕ·ÃÎÊÁ¿ÒÑ³¬Íò´Î£¬7ÔÂ·Ý·ÃÎÊÖ÷Ò³Á¿´ï35Íò´Î¡£
--
±¾ÍøÕ¾¿ªÕ¹µÄÓÐ³¥·þÎñÄÚÈÝ°üÀ¨£º

Ö÷Ò³µÄLogo±êÊ¶¡¢¸÷ÆµµÀµÄLogo±êÊ¶£¬¾ùÔÚÏÔÖøµÄÎ»ÖÃ£¬²¢ÇÒÌá¹©×¨ÓÃÍøÒ³Á´½Ó£¬¼Û¸ñÊµÐÐÓÃ»§×ÔÔ¸¸¶¿î¶î·½Ê½£¨ÔÒòÊÇÎªÁËÍøÕ¾µÄÉú´æ£¬ÒÔ±ãÄÜ±£Ö¤³¤¾ÃµØÎª¾ÍÒµÕß¡¢ÕÐÆ¸µ¥Î»µÈ²¿ÃÅÌá¹©Ãâ·Ñ·þÎñ£¬´Ù½øÉç»á¹«ÒæÊÂÒµµÄ·¢Õ¹£©,logoÍ¼Æ¬³ß´çÎª100pxX100pxÒÔÄÚ£¬ÈçÓÐÌØÊâÒªÇó¿ÉÐÉÌ£¬ÓÃ»§¸ù¾Ý×Ô¼ºµÄ¹ã¸æÐ§¹û¼°±¾Õ¾µÄ·þÎñÖÊÁ¿£¬¸øÓèÎÒÃÇÒ»¸ö¾¼ÃÉÏµÄÖ§³Ö£¬±¾ÍøÕ¾Ä¿Ç°²»Ìá¹©¼ÛÄ¿±í£¬ÓÉÓÃ»§×Ô¶¨¡£»¶ÓÔÚ¾ÍÒµÔÚÏßÍøÕ¾ÉÏ¿¯µÇ¸÷Àà¹ã¸æÐÅÏ¢£¡
--
ÍøÕ¾ºÏ×÷ÊÂÏî£º
   (1) 
±¾Õ¾ÓûÓëÒ»ÇÐÄÚÈÝ½¡¿µ¡¢·ûºÏ¹ú¼Ò·¨ÂÉ·¨¹æµÄÍøÕ¾½øÐÐºÏ×÷£¬ºÏ×÷·ÖÎªÓÑÇéÁ´½Ó£¨½ö×öÁ´½Ó£©ºÍÕ½ÂÔÍ¬ÃË£¨×öÍøÕ¾Ðû´«½éÉÜ¼°Á´½Ó£©¡£»¶Ó¸øÓè¾ÍÒµÔÚÏß×öÓÑÇéÁ´½Ó»òÀ´µç£¨º¯£©ÉÌÌ¸ÍøÕ¾ºÏ×÷ÊÂÏî¡££¨±¾Õ¾Logo±êÊ¶ÏÂÔØ150pxX40px»ò100pxX40px£©
   
(2£©Ï£ÍûÓë³ÉÈË½ÌÓýÔºÐ£¼°ÅàÑµµ¥Î»¡¢ÖÂ¸»ÊµÓÃ¼¼Êõ£¨Í¶×ÊÐ¡£¬Ð§ÒæºÃ£©¿ª·¢ÑÐ¾¿²¿ÃÅ¡¢³ö°æÖ°Òµ¼¼ÄÜÅàÑµÊé¼®µÄµ¥Î»µÈ½øÐÐºÏ×÷£¬ÎÒÃÇÎªÄúÃâ·Ñ×ö½éÉÜÐû´«¡¢ÄúÎª¾ÍÒµÕßÌá¹©Ñ§Ï°¡¢ÅàÑµ¼°ÖÂ¸»µÄ»ú»á¡£ÎÒÃÇÔ¸ÓëÄú¹²Í¬·¢Õ¹¡¢¹²Í¬Ç°½ø£¡
--

ÎªÁËºëÑïÄÇÐ©ÏÂ¸Ú²»ÂäÖ¾£¬Ñ°¸ÚÔÙ´´Òµ¿¬Ä£ÃÇµÄ¸ÐÈËÊÂ¼££»»¹ÎªÁËÔÞÑïÄÇÐ©Îª°ïÖú¡¢Ö§³ÖºÍÔ®ÖúÏÂ¸ÚÈËÔ±ÔÙ¾ÍÒµµÄÎÞË½·îÏ×¸ß·çÁÁ½ÚµÄÈËÃÇ¡£±¾ÍøÕ¾ÕýÔÚ³ï±¸¡°ÔÙ¾ÍÒµ¿¬Ä£¡±ÆµµÀ£¬ÅÎÍûµÃµ½Éç»á¸÷½çÈËÊ¿µÄÖ§³Ö¡¢°ïÖú£¬Ìá¹©Õâ·½ÃæµÄ¸ÐÈË·Î¸ÏÈ½øÊÂ¼£µÄ²ÄÁÏ¡£
--
ÎÒÃÇµÄµÀÇ¸£º
   Èç¹û´Ë·âE-mail¸øÄúÌí¼ÓÁËÂé·³£¬¾´ÇëÔÁÂ£¡Ò²¸ÐÐ»ÄúÔÄ¶Á´Ë·âE-mail£¬ÔÚ´ËÖÂÐ»£¡
--
¹ØÐÄ¹«ÒæÊÂÒµ£¬ºëÑïÖÐ»ªÓÅÁ¼´«Í³£¡
--
ÍøÖ·£ºwww.¾ÍÒµÔÚÏß.¹«Ë¾£¬www.91online.net
µç×ÓÐÅÏä£º[EMAIL PROTECTED],[EMAIL PROTECTED]
£¨China)In Work Online Information Co.,Ltd.
Í¨ÐÅµØÖ·£º°²»ÕÊ¡Âí°°É½ÊÐºþ¶«Èý´å£²£²¶°£¶£°£´ÐÅÏä
ÓÊÕþ±àÂë£º243011

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] enable truetype string function in gd

2001-09-24 Thread Thomas Wentzel

I realized that just after posting my question... Though solving my
configure problem I still can't get freetype to work...
I had everything running under php-4.0.4 (including gd and freetype 1.x)
However due to the patent issues it is necessary for me to use freetype2
which isn't too bad in itself ;)
Well...
I saw an "old" submission from Wez claiming that the problems I were 
experiencing wasn't a PHP problem, but rather a gd problem. I tried out
the little C program he included and true enough - The problem was, that
gd for some reason didn't include TrueType support (allthough everything
suggested that it ought to)... Well after searching high and low - I
found
this excellent :) link, http://www.alt-php-faq.org/local/68/ , which
says
that gd-1.8.x doesn't support freetype2 - and how to successfully
compile
gd and freetype into PHP. I realize that this has little to do as such
with
the forum of this mailing list, but I also believe, that many get their
first 
experience with gd end freetype when trying to compile it into php,
which sort
of justifies my entry ;)
Ho hum... Now I have everything up and running - or so it would seem,
but when
I try to utilize the imagettfbbox og imagettftext functions I get an
error saying
"Could not find/open font". In light of the troubles with gd and
freetype - it would 
seem likely that this problem also stems from that and not PHP - but I'm
asking here 
anyway - because it seems that this forum is much more active than the
various gd and 
freetype forums.
Another thing... I ran through the ext/gd sources and found some
functions (not included
in the manual pages) namely imageftbbox and imagefttext, but whenever I
try to use these
functions I get an error saying that freetype2 support wasn't included
in the PHP build (??)
Can anybody shed some light on this?

Thomas

Rasmus Lerdorf wrote:
> 
> > I try to get the above mentioned to work with the 4.0.6 release on
> > Linux!
> >
> > But even though I provide the configure script with the
> > --enable-gd-native-ttf
> > switch, it reports that the feature is a no go
> 
> There was a slight buglet in 4.0.6.  Use
> 
>   --enable-gd-native-tt
> 
> instead.
> 
> -Rasmus
> 
> --
> PHP Development Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #13412: IMAP don't compile propertly

2001-09-24 Thread autoinfo


From: [EMAIL PROTECTED]
Operating system: FreeBSD 4.4-RC
PHP version:  4.0.6
PHP Bug Type: *General Issues
Bug description:  IMAP don't compile propertly

I have :
c-client library
All headers are deployed in /usr/local/include/c-client directory.

My config-file for make is :
 QUOTE
-
./configure \
--with-mod_charset \
--enable-track-vars \
--enable-sysvsem \
--enable-sysvshm \
--enable-shared \
--with-apache=/usr/local/src/apache \
--with-pgsql=/usr/local/pgsql \
--with-mysql=/usr/local \
--with-gd=/usr/local \
--with-jpeg-dir=/usr/local \
--without-ttf \
--without-ndbm \
--without-dbm \
--without-gdbm \
--with-imap \
--with-xml > /dev/null
 EDN OF QUOTE
-


Then, when I'm trying to configure Apache, the process stops, as described
below:
 QUOTE
-
Configuring for Apache, Version 1.3.20
 + using installation path layout: Apache (config.layout)
 + activated php4 module (modules/php4/libphp4.a)
 + activated auth_pgsql module (modules/auth_pgsql/mod_auth_pgsql.c)
 + activated rru module (modules/extra/mod_rru.o)
 + activated auth_mysql module (modules/auth_mysql/libauth_mysql.a)
Creating Makefile
Creating Configuration.apaci in src
Creating Makefile in src
 + configured for FreeBSD 4.4 platform
 + setting C pre-processor to gcc -E
 + checking for system header files
 + adding selected modules
o charset_module uses ConfigStart/End
o php4_module uses ConfigStart/End
o auth_pgsql_module uses ConfigStart/End
o auth_mysql_module uses ConfigStart/End
 + checking sizeof various data types
 + doing sanity check on compiler and options
** A test compilation with your Makefile configuration
** failed.  The below error output from the compilation
** test will give you an idea what is failing. Note that
** Apache requires an ANSI C Compiler, such as gcc.

cd ..; gcc  -I/usr/local/include/mysql  -funsigned-char -DRUSSIAN_APACHE
-I/usr/
local/src/php -I/usr/local/src/php/main -I/usr/local/src/php/main
-I/usr/local/s
rc/php/Zend -I/usr/local/src/php/Zend -I/usr/local/src/php/TSRM
-I/usr/local/src
/php/TSRM -I/usr/local/src/php -DUSE_EXPAT -I./lib/expat-lite
-DNO_DL_NEEDED `./
apaci` -o helpers/dummy helpers/dummy.c   -L/usr/local/lib/mysql
-lmysqlclie
nt -lcrypt   -L/usr/local/pgsql/lib -lpq  -R/usr/local/lib
-R/usr/local/lib/mysq
l -R/usr/local/pgsql/lib  -rdynamic -L/usr/local/lib -L/usr/local/lib/mysql
-L/u
sr/local/pgsql/lib -Lmodules/php4 -L../modules/php4 -L../../modules/php4
-lmodph
p4  -lpam -lc-client4  -lpq -lmysqlclient -lcrypt -lpam -lgd -ljpeg -lcrypt
-lm
 -lcrypt   -lcrypt
/usr/local/lib/libc-client4.so: undefined reference to `mm_expunged'
/usr/local/lib/libc-client4.so: undefined reference to `mm_diskerror'
/usr/local/lib/libc-client4.so: undefined reference to `mm_lsub'
/usr/local/lib/libc-client4.so: undefined reference to `mm_flags'
/usr/local/lib/libc-client4.so: undefined reference to `mm_fatal'
/usr/local/lib/libc-client4.so: undefined reference to `mm_nocritical'
/usr/local/lib/libc-client4.so: undefined reference to `mm_notify'
/usr/local/lib/libc-client4.so: undefined reference to `mm_searched'
/usr/local/lib/libc-client4.so: undefined reference to `mm_status'
/usr/local/lib/libc-client4.so: undefined reference to `mm_login'
/usr/local/lib/libc-client4.so: undefined reference to `mm_list'
/usr/local/lib/libc-client4.so: undefined reference to `mm_critical'
/usr/local/lib/libc-client4.so: undefined reference to `mm_exists'
 EDN OF QUOTE
-

Also, I've tried to compile IMAP with PHP 4.0.6 and with snaps version,
with I have obtained from 
http://snaps.php.net:8080/php4-200109240135.tar.gz
Unfortunately, the result was same...

-- 
Edit bug report at: http://bugs.php.net/?id=13412&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #10918 Updated: $HTTP_POST_VARS incorrectly initialized.

2001-09-24 Thread bruce


ID: 10918
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Old Status: Closed
Status: Open
Bug Type: Variables related
Operating System: Linux 2.4.3
PHP Version: 4.0.5
New Comment:

It appears this problem as I described earlier does exists in PHP 4.0.6.

Previous Comments:


[2001-06-12 17:19:56] [EMAIL PROTECTED]

No feedback, considered fixed.




[2001-05-23 02:14:51] [EMAIL PROTECTED]

I'm unable to reproduce this with PHP 4.0.6RC1.
Please try it: http://www.php.net/~andi/php-4.0.6RC1.tar.gz

And also, replace your php.ini with the php.ini-dist that
comes with the package. Then change the appropriate directives.

--Jani




[2001-05-17 00:39:47] [EMAIL PROTECTED]

Array variables acquired via the POST method do not appear in the $HTTP_POST_VARS 
array unless magic_quotes_gpc is DISABLED.

For example, if one uses a checkbox array named thus:





an array variable called $fred will appear in the global namespace (assuming 
register_globals is ON). The same array variable should also appear as 
$HTTP_POST_VARS["fred"] (assuming track_vars is ON).

The BUG results in $HTTP_POST_VARS["fred'] appearing, but not as an array variable. 
That is, is_array($HTTP_POST_VARS["fred"]) returns FALSE. Further, the value of 
$HTTP_POST_VARS["fred"] is the string literal "Array" which curiously is the same 
string returned when an array variable is accessed in a scalar context.

If magic_quotes_qpc is DISABLED, this problem vanishes and the value of 
$HTTP_POST_VARS["fred"] is the anticipated array of values of selected checkboxes.

It looks to me like PHP4 is storing the result of a scalar access to the array 
variable $fred in $HTTP_POST_VARS["fred"] when magic_quotes_gpc is enabled. I think 
this qualifies as a bug.





Edit this bug report at http://bugs.php.net/?id=10918&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #13134 Updated: ftp_put couldn't open local file

2001-09-24 Thread john . fleuret


ID: 13134
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: FTP related
Operating System: windows NT
PHP Version: 4.0.5
New Comment:

Sorries,

1-Sorry, It was a human error (ok, i'm this human), my distant path was wrong
2-Sorry for the response time, i was go away on holiday.
Thanks for your interest
John 

Previous Comments:


[2001-09-22 11:59:01] [EMAIL PROTECTED]

No feedback, so closing

Derick



[2001-09-04 12:07:43] [EMAIL PROTECTED]

Can you provide a sample script?



[2001-09-04 11:30:49] [EMAIL PROTECTED]

ftp_put couldn't open local file to transfert on remote





Edit this bug report at http://bugs.php.net/?id=13134&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #6662 Updated: array keys of type real not allowed?

2001-09-24 Thread jeroen


ID: 6662
Updated by: jeroen
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: Scripting Engine problem
Operating System: linux
PHP Version: 4.0.2
New Comment:

>From the docs (by heart): in object initializers only constant scalar experssions are 
>allowed, no arrays, objects, or expressions, only simple int/float/etc.

That's incorrect thus? Should be 'only constant values', because arrays and 'new 
Object()' are allowed? Or arrays only?

IMO, it should be the case, but I don't know wether it's supported in ZE1.

Previous Comments:


[2001-05-06 11:38:46] [EMAIL PROTECTED]

Fixed in the CVS - thanks for your report!



[2000-09-16 17:00:56] [EMAIL PROTECTED]

Float keys don't work, the variable gets converted to integer. This, however, doesn't 
work with array initializers - this should be fixed.



[2000-09-11 22:06:25] [EMAIL PROTECTED]

It seems that array keys of type real are not allowed in class declaration:

class MyClass {
 var $a = array( 1.5=>1, 3.5=>2, 7.5=>5, 99=>10);
 ...
}

Results in only one item 99=>10 in array.

Above is accepted in PHP3.

Workaround:

 var $a = array( '1.5'=>1, '3.5'=>2, '7.5'=>5, '99'=>10);







Edit this bug report at http://bugs.php.net/?id=6662&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

62 matches

Mail list logo