[PHP-DEV] ANNOUNCE: XML based Meta-Language compiler written in PHP

[Manuel Lemos]

Hello,

I was not willing to tell so soon, but since I am going to make a
presentation of this at the O'Reilly Open Source Convention:  XTech 2001:
Cutting Edge XML, and the Early Bird price deadline is about to end for
those that may want to attend, I am announcing a special application that I
have been developing completely written in PHP.

For the last 2 years I have been developing a XML based Meta-Language
compiler named MetaL.  It would take a long message to describe what it can
do and what are its advantages.

To summarize, basically it lets you use XML as source code of completely
redefinable programming language.  The compiler that I developed in PHP is
a modular application that translates XML commands into code of traditional
programming languages like PHP, but may be in anything else.

This is not a replacement for traditional languages, but rather a powerful
development tool for general improvement of software development methods.

Many PHP users already know something about this because I announced in the
PHP Classes site newsletter, but for those that are not yet aware, the
abstract for the presentation at O'Reilly Open Source Convention is here:

http://groups.yahoo.com/group/metal-dev/files/MetaL-Introduction.txt

The HTML presentation slides are here:

http://groups.yahoo.com/group/metal-dev/files/metal.tar.gz

or 

http://groups.yahoo.com/group/metal-dev/files/metal.zip

A 2-up printable version of the slides is here:

http://groups.yahoo.com/group/metal-dev/files/metal.pdf


The description of my talk on MetaL at the convention is here:

http://conferences.oreillynet.com/cs/os2001/view/e_sess/1874

The Early bird price for those that would like to attend to the whole
connvetion may be $400 off if you register before July 2.

If you are a member of O'Reilly user group you can have an additional 20%
discount.

The PHP Classes site subscribers are effectively members of an O'Reilly
user group.  If you are a subscriber of the PHP Classes site, just mail me
so I let you know how to get the user group discount.  If you are not a
subscriber, you may subscribe here:

http://phpclasses.UpperDesign.com/browse.html?login=1&subscribe=1


Regards,
Manuel Lemos

Web Programming Components using PHP Classes.
Look at: http://phpclasses.UpperDesign.com/?[EMAIL PROTECTED]
--
E-mail: [EMAIL PROTECTED]
URL: http://www.mlemos.e-na.net/
PGP key: http://www.mlemos.e-na.net/ManuelLemos.pgp
--


-- 
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 #11647: Installation Failure

[info]

From: [EMAIL PROTECTED]
Operating system: Linux (Intel glibc)
PHP version:  4.0.6
PHP Bug Type: Apache related
Bug description:  Installation Failure

Script:

su
cp /usr/sbin/httpd /usr/bin/httpd
cd /tmp
gzip -d php-4.0.6.tar.gz
tar -xvf php-4.0.6.tar
cd php-4.0.6
./configure --prefix=/usr/local/php-4.0.6 --exec-prefix=/usr/local/php-4.0.6 
--with-apxs=/usr/sbin/apxs --with-mysql=/usr/local/mysql
make
make install

Description:

At this point, the installation process fails because the 'make install' script 
invokes APXS. APXS runs, but responds that it does not understand the -S flag, which 
is visibly being used. This takes place when running Apache/1.3.6 with mod_perl/1.21, 
mod_ssl/2.2.8, and OpenSSL/0.9.2b on a Cobalt RaQ 3i system with all of the latest 
patches from Cobalt installed.

This problem did not occur with any previous versions of PHP. PHP 4.0.5 installs 
perfectly.


-- 
Edit Bug report at: http://bugs.php.net/?id=11647&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] About ext/sockets/

[Andi Gutmans]

At 08:21 PM 6/24/2001 +0200, Jani Taskinen wrote:

>What new functionality? Why the hell should the API change?
>Only the function names should have been changed, not break
>the whole extension!

It's a rewrite which is more in the PHP spirit. i.e. return true/false and 
not -1/0 and stuff like that (if I understood correctly).

Andi


-- 
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-DOC] Re: [PHP-DEV] Bug #11645 Updated: tempnam( ) does not use TMP environment variable

[Daniel Beckham]

It's not so much that we can not go and view the open documentation bugs,
but that due to the very tiny number of documenation bugs that are
submitted, looking at it on a daily basis is a waste of time.

I imagine that, the reason it hasn't happened yet is due to technical
issues, but it's a very valid point.  It would be best if the documenation
bugs submitted were cc'ed to this list.

Daniel

- Original Message -
From: "Jani Taskinen" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Sunday, June 24, 2001 7:19 PM
Subject: [PHP-DOC] Re: [PHP-DEV] Bug #11645 Updated: tempnam( ) does not use
TMP environment variable


>
> You don't have to follow php-dev to catch these,
> just point your browser to this URL:
>
>
http://www.php.net/bugs.php?cmd=Display+Bugs&status=Open&bug_type=Documentat
ion+problem&by=Any
>
> --Jani
>
>
> On Mon, 25 Jun 2001 [EMAIL PROTECTED] wrote:
>
> >> This is documentation problem.
> >
> >=>
> >
> >This brings me to another point, since not-so-long-ago there is a
> >phpdoc/TODO file, and we would greatly appreciate it that an entry is
added
> >whenever there is a substantial change to PHP which should be documented.
Of
> >course, it'd even better if you instead update the docs yourself ;-).
> >Updating the TODO will increase the likelyhood that the documentation
will
> >be updated soon. If you don't have Karma to phpdoc, get it, or simply
mail
> >[EMAIL PROTECTED]
> >
> >This also applies to documenation problems like this one. They should IMO
at
> >least be cross-posted to phpdoc@, so the phpdoc ppl don't need to follow
> >phpdev.
> >
> >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 #11646 Updated: Cant get php for linux

[rasmus]

ID: 11646
Updated by: rasmus
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: *General Issues
Operating system: 
PHP Version: 4.0.6
Assigned To: 
Comments:

What in heaven's name are you talking about?  There is no difference between accessing 
the site with Windows and Linux.  No detection is going on.  

Previous Comments:
---

[2001-06-24 22:39:08] [EMAIL PROTECTED]
I can't get my winmodem working with linux, i download everything i need to a win 
share then install to linux. Your platform detection is most shortsighted. Why can't i 
download a linux version if i logon to your site with win. This is so frustrating as i 
need a new version 4.0.3+ but can't get it. Please tell your web designer to jump in a 
river and drown.

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=11646&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 #11646: Cant get php for linux

[0712388]

From: [EMAIL PROTECTED]
Operating system: win/linux
PHP version:  4.0.6
PHP Bug Type: *General Issues
Bug description:  Cant get php for linux

I can't get my winmodem working with linux, i download everything i need to a win 
share then install to linux. Your platform detection is most shortsighted. Why can't i 
download a linux version if i logon to your site with win. This is so frustrating as i 
need a new version 4.0.3+ but can't get it. Please tell your web designer to jump in a 
river and drown.


-- 
Edit Bug report at: http://bugs.php.net/?id=11646&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 #11634 Updated: Submit error

[mbeech13]

ID: 11634
User Update by: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Open
Bug Type: HTTP related
Operating system: Win2K Pro SP2
PHP Version: 4.0.6
Description: Submit error

the best i can do at the moment is the error log message:
Premature end of script headers: c:/php/php.exe

If i can find the time i will find the script, maybe that will help some.

Previous Comments:
---

[2001-06-23 18:45:44] [EMAIL PROTECTED]
Please include a shortest but complete script you can
reproduce the error with into this bug report.



---

[2001-06-23 18:29:10] [EMAIL PROTECTED]
Whenever someone tries to submit to my site they get the
error "No input file specified"

I think it may have something to do with this code here:

case "post":
postNews($userinfo["user_id"],
$HTTP_POST_VARS["topic"], $HTTP_POST_VARS["section"],
$HTTP_POST_VARS["title"], $HTTP_POST_VARS["department"],
$HTTP_POST_VARS["text"], $HTTP_POST_VARS["text2"],
$HTTP_POST_VARS["format"], 1);
printHeader("$site_title - Submission Posted")

But i am not sure.

Anyone know what I might be able to do?

---


Full Bug description available at: http://bugs.php.net/?id=11634


-- 
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 #11644 Updated: Interbase dll causes PWS ISAPI to die

[jlim]

ID: 11644
User Update by: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Open
Bug Type: InterBase related
Operating system: Windows ME
PHP Version: 4.0.6
Description: Interbase dll causes PWS ISAPI to die

>
Did you update your extensions from the new release?

Yes I did. I renamed my old php directory to php404 and recreated the php directory 
from scracth.

I copied all the dlls in the dll folder to my windows\system directory and rebooted 
also.

-- John

Previous Comments:
---

[2001-06-24 17:49:27] [EMAIL PROTECTED]
Did you update your extensions from the new release?


---

[2001-06-24 14:05:30] [EMAIL PROTECTED]
Upgraded from PHP 4.0.4pl1 to PHP 4.0.6. Did not modify my php.ini. 

After the upgrade, I ran a test script with phpinfo() to see if the upgrade worked, 
and PWS died immediately.

By commenting out my extensions one by one, I discovered the culprit was 
php_interbase.dll. With only that extension removed, everything works fine using 
ISAPI.

When I use CGI with interbase, everything works fine. Perhaps the interbase dll is not 
100% thread safe?

Thanks for reading this, John

---


Full Bug description available at: http://bugs.php.net/?id=11644


-- 
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] Bug #11645 Updated: tempnam( ) does not use TMPenvironment variable

[Jani Taskinen]

You don't have to follow php-dev to catch these,
just point your browser to this URL:

http://www.php.net/bugs.php?cmd=Display+Bugs&status=Open&bug_type=Documentation+problem&by=Any

--Jani


On Mon, 25 Jun 2001 [EMAIL PROTECTED] wrote:

>> This is documentation problem.
>
>=>
>
>This brings me to another point, since not-so-long-ago there is a
>phpdoc/TODO file, and we would greatly appreciate it that an entry is added
>whenever there is a substantial change to PHP which should be documented. Of
>course, it'd even better if you instead update the docs yourself ;-).
>Updating the TODO will increase the likelyhood that the documentation will
>be updated soon. If you don't have Karma to phpdoc, get it, or simply mail
>[EMAIL PROTECTED]
>
>This also applies to documenation problems like this one. They should IMO at
>least be cross-posted to phpdoc@, so the phpdoc ppl don't need to follow
>phpdev.
>
>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] Bug #11645 Updated: tempnam( ) does not use TMP environment variable

[jeroen]

> This is documentation problem.

=>

This brings me to another point, since not-so-long-ago there is a
phpdoc/TODO file, and we would greatly appreciate it that an entry is added
whenever there is a substantial change to PHP which should be documented. Of
course, it'd even better if you instead update the docs yourself ;-).
Updating the TODO will increase the likelyhood that the documentation will
be updated soon. If you don't have Karma to phpdoc, get it, or simply mail
[EMAIL PROTECTED]

This also applies to documenation problems like this one. They should IMO at
least be cross-posted to phpdoc@, so the phpdoc ppl don't need to follow
phpdev.

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] About ext/sockets/

[Zeev Suraski]

At 03:23 25/6/2001, Brian Tanner wrote:
>Considering a very low % of PHP programmers have extensive C socket
>experience, I wouldn't worry too much  about making it inconvenient.  You
>guys are just a little biased (IMHO), because you are all talented,
>experienced, C programmers.

Not all of us are biased :)  I think that the C socket API has no room in PHP.

Zeev


-- 
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] Bug #11619 Updated: Socket function examples scripts aren't working with latest CVS

[jeroen]

> Assigned the documentation to person who is
> to thank for this better API.

I'm not sure whether he's happy with that, taking in mind
that documention is often seen as a necessary evil ;)




-- 
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 #11619 Updated: Socket function examples scripts aren't working with latest CVS

[sniper]

ID: 11619
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Assigned
Old-Bug Type: Sockets related
Bug Type: Documentation problem
Operating system: 
PHP Version: 4.0 Latest CVS (2001-06-22)
Assigned To: dbeu
Comments:

Try the example found here:

http://introverted.com/php-sockets.html

It works just fine for me. 
The API was changed to be more PHPish.

Assigned the documentation to person who is 
to thank for this better API.

--Jani


Previous Comments:
---

[2001-06-22 13:25:20] [EMAIL PROTECTED]
After checking the renamed socket functions, i tried to get the sockets example script 
running. It works fine under 4.0.5, so i renamed the functions to the new ones, und 
tried to get it running. It started, and i could connect without problems, but instead 
of being an echo server, i just got disconnectet. 
When are the new sockets function getting documented with an example script ?
thx in advance

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=11619&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]

RE: [PHP-DEV] About ext/sockets/

[Jani Taskinen]

Thanks for the example. It worked just fine on my Linux box.
I was just being a bit too lazy I guess.. :)

--Jani

On Sun, 24 Jun 2001, Brian Tanner wrote:

>Just thought I'd pipe up on this topic, cause its very applicable.
>
>I'm a 4th year Honours CompSci student.  I've written some client server
>stuff in C (hence a little sockets experience), and I have been using PHP
>for a year now.
>
>My *only* complaint of PHP is that all the really fun stuff (memory sharing,
>sockets, couple of others) doesn't work for Windows.
>
>I've coded sockets for *nix in C before, but I am rusty.  It took me 30
>minutes to get familiar and start coding with the new API.  The changes are
>are very straightforward, and make the socket extension work more like the
>rest of PHP.  Returning "0" for success and negative numbers just isn't how
>PHP does things.
>
>http://introverted.com/php-sockets.html
>
>Considering a very low % of PHP programmers have extensive C socket
>experience, I wouldn't worry too much  about making it inconvenient.  You
>guys are just a little biased (IMHO), because you are all talented,
>experienced, C programmers.
>
>Anyway.. basically just wanted to say that I have used the new API, it works
>well, and I was very happy to see sockets making it to windows.
>
>-Brian Tanner
>
>
>
>
>
>-Original Message-
>From: Sascha Schumann [mailto:[EMAIL PROTECTED]]
>Sent: June 24, 2001 2:19 PM
>To: [EMAIL PROTECTED]
>Cc: [EMAIL PROTECTED]
>Subject: Re: [PHP-DEV] About ext/sockets/
>
>
>Jeroen,
>
>> For lower-scale and home-use you can argue it is easier
>> than *nix. So when possible, you should try to support windows.
>[..]
>> > [looked like C, was easier for ppl with C-background]
>>
>> I don't think you should target php at C-ppl.
>
>PHP has been since its inception strongly influenced by C.
>And as a tool originally conceived on Unix, it should
>maintain its roots and continue to provide people familiar
>with Unix APIs a convenient way for scripting.
>
>Thus, improved Windows support should not come at the expense
>of Unix support without a perfect reason.  I'm missing that
>reason here.
>
>I haven't looked deeply at what API changes have been
>introduced lately, but I'd suggest to use the standard BSD
>sockets return value semantics (-1 for failure, >= 0 for
>success).  Those semantics also prevail in the Winsock
>implementation, so they should be quite natural.
>
>- 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 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] About ext/sockets/

[Jani Taskinen]

On Mon, 25 Jun 2001, Zeev Suraski wrote:

>At 22:10 24/6/2001, Jani Taskinen wrote:
>>So this is broken now only on *nix? Nice.
>>Previously it worked only on unices, now it works only on win32?
>>What an improvement.
>
>Let's keep cynicism off this list, please...

:-p

>About the socket extension - this was discussed, and agreed upon that the
>way it worked was *wrong* and against the PHP spirit.  The fact it was also

Okay..I don't remember this discussion. But I see the point.

>tagged as experimental makes it easier for us to change the API to a
>PHP-like API, even though it would have probably been the right thing to do
>even if it didn't have the experimental tag.

BTW. Have you noticed that I am now the one against breaking BC and
YOU want to do it? Did someone switch our brains or what? :)

>This does not come to say that it's ok that it's now broken under UNIX, or
>how the change was done (I don't remember so I won't comment about it).  It
>does come to say that the general change was a good idea.

This is the reason I got pissed. It worked fine before the change..now
it's useless. But Sterling had some fixes pending. Maybe it's okay
after those are committed. Also, I would like to see the manual
updated ASAP.

--Jani



-- 
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] About ext/sockets/

[Brian Tanner]

Just thought I'd pipe up on this topic, cause its very applicable.

I'm a 4th year Honours CompSci student.  I've written some client server
stuff in C (hence a little sockets experience), and I have been using PHP
for a year now.

My *only* complaint of PHP is that all the really fun stuff (memory sharing,
sockets, couple of others) doesn't work for Windows.

I've coded sockets for *nix in C before, but I am rusty.  It took me 30
minutes to get familiar and start coding with the new API.  The changes are
are very straightforward, and make the socket extension work more like the
rest of PHP.  Returning "0" for success and negative numbers just isn't how
PHP does things.

http://introverted.com/php-sockets.html

Considering a very low % of PHP programmers have extensive C socket
experience, I wouldn't worry too much  about making it inconvenient.  You
guys are just a little biased (IMHO), because you are all talented,
experienced, C programmers.

Anyway.. basically just wanted to say that I have used the new API, it works
well, and I was very happy to see sockets making it to windows.

-Brian Tanner





-Original Message-
From: Sascha Schumann [mailto:[EMAIL PROTECTED]]
Sent: June 24, 2001 2:19 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: [PHP-DEV] About ext/sockets/


Jeroen,

> For lower-scale and home-use you can argue it is easier
> than *nix. So when possible, you should try to support windows.
[..]
> > [looked like C, was easier for ppl with C-background]
>
> I don't think you should target php at C-ppl.

PHP has been since its inception strongly influenced by C.
And as a tool originally conceived on Unix, it should
maintain its roots and continue to provide people familiar
with Unix APIs a convenient way for scripting.

Thus, improved Windows support should not come at the expense
of Unix support without a perfect reason.  I'm missing that
reason here.

I haven't looked deeply at what API changes have been
introduced lately, but I'd suggest to use the standard BSD
sockets return value semantics (-1 for failure, >= 0 for
success).  Those semantics also prevail in the Winsock
implementation, so they should be quite natural.

- 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 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] About ext/sockets/

[Zeev Suraski]

Sascha,

PHP is an established language on its own now, with failure semantics of 
its own.  Failure in PHP is noted by false and resource (i.e. anything 
which is not a language primitive or composite type) are contained in 
IS_RESOURCE handles.  The original socket implementation was wrong in the 
sense that it used non-PHP semantics, thus being both non intuitive for the 
PHP user and inconsistent with the language.  It doesn't really matter how 
popular the semantics it followed was;  It was wrong for PHP.  FWIW, from 
my experience, most PHP users do not come from a UNIX system programming 
background, not that it really matters in this case.  People who use PHP 
should see that it is consistent, and should not be required to be familiar 
with Unix or Winsock APIs.

Zeev

At 00:18 25/6/2001, Sascha Schumann wrote:
> Jeroen,
>
> > For lower-scale and home-use you can argue it is easier
> > than *nix. So when possible, you should try to support windows.
>[..]
> > > [looked like C, was easier for ppl with C-background]
> >
> > I don't think you should target php at C-ppl.
>
> PHP has been since its inception strongly influenced by C.
> And as a tool originally conceived on Unix, it should
> maintain its roots and continue to provide people familiar
> with Unix APIs a convenient way for scripting.
>
> Thus, improved Windows support should not come at the expense
> of Unix support without a perfect reason.  I'm missing that
> reason here.
>
> I haven't looked deeply at what API changes have been
> introduced lately, but I'd suggest to use the standard BSD
> sockets return value semantics (-1 for failure, >= 0 for
> success).  Those semantics also prevail in the Winsock
> implementation, so they should be quite natural.
>
> - 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]

--
Zeev Suraski <[EMAIL PROTECTED]>
CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 
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] About ext/sockets/

[Zeev Suraski]

At 22:10 24/6/2001, Jani Taskinen wrote:
>So this is broken now only on *nix? Nice.
>Previously it worked only on unices, now it works only on win32?
>What an improvement.

Let's keep cynicism off this list, please...

About the socket extension - this was discussed, and agreed upon that the 
way it worked was *wrong* and against the PHP spirit.  The fact it was also 
tagged as experimental makes it easier for us to change the API to a 
PHP-like API, even though it would have probably been the right thing to do 
even if it didn't have the experimental tag.

This does not come to say that it's ok that it's now broken under UNIX, or 
how the change was done (I don't remember so I won't comment about it).  It 
does come to say that the general change was a good idea.

Zeev


-- 
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 #11644 Updated: Interbase dll causes PWS ISAPI to die

[sniper]

ID: 11644
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Bug Type: InterBase related
Operating system: 
PHP Version: 4.0.6
Assigned To: 
Comments:

Did you update your extensions from the new release?


Previous Comments:
---

[2001-06-24 14:05:30] [EMAIL PROTECTED]
Upgraded from PHP 4.0.4pl1 to PHP 4.0.6. Did not modify my php.ini. 

After the upgrade, I ran a test script with phpinfo() to see if the upgrade worked, 
and PWS died immediately.

By commenting out my extensions one by one, I discovered the culprit was 
php_interbase.dll. With only that extension removed, everything works fine using 
ISAPI.

When I use CGI with interbase, everything works fine. Perhaps the interbase dll is not 
100% thread safe?

Thanks for reading this, John

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=11644&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]

Re: [PHP-DEV] Bug #11611 Updated: nl2br() outputting invalid tags

[Daniel Beckham]

The point of this is...  is complaint with existing html standards and
the new xhtml standard.  While  is *not* compliant with new XHTML
standards.  Why make the programmers go back and make changes for no reason?
Or for reasons like "It's pointless to output  tags in HTML 4 code."?

Daniel

- Original Message -
From: <[EMAIL PROTECTED]>
To: "Lenar Lõhmus" <[EMAIL PROTECTED]>
Cc: "Matt McClanahan" <[EMAIL PROTECTED]>; "PHP Developers Mailing List"
<[EMAIL PROTECTED]>
Sent: Sunday, June 24, 2001 4:13 PM
Subject: Re: [PHP-DEV] Bug #11611 Updated: nl2br() outputting invalid 
tags


> On Sun, 24 Jun 2001, [iso-8859-15] Lenar Lõhmus wrote:
>
> >
> > Yes, agree, but this change has happend not much time ago, and I think
> > it's one's responsibility to maintain the behavior what it used to
> > be. Even more if the old syntax was generating standard compliant code
> > (and HTML4 is a standard).
>
> This syntax is perfectly html 4.01 (transistional) compliant.
> (Try requesting this link through validator.w3.org:
> http://defiant.jdimedia.nl:7480/php-hacking/php11611.php (only works
> during night hours in GMT)
>
> >
> > Still, we must evolve, so a syntax like
> > nl2br(string text [boolean html4]) would give the most up to date
> > behaviour of this function, giving somebody an option to get the old
> > behaviour when it's really neccessary.
>
> It is never neccesary, unless Microsoft (or any other) wrote a browser
> that is not adhering to the standards.
>
> >
> > And ... you don't know a browser where  dowsn't work? But there
> > might be one ... one's own specific implementation where creator haven't
> > thought up possibility that "" might be "" one day. Since it
is
> > not neccessary for HTML to recognize "/" in the end of single tag then
we
> > can't really blame him.
>
> Browsers should ignore things which they don't recognise:
> (from http://www.w3.org/TR/1999/REC-html401-19991224/html40.txt, paragraph
> 7.2)
>
>Note. As of the 24 December version of HTML 4.01, the HTML Working
>Group commits to the following policy:
>  * Any changes to future HTML 4 DTDs will not invalidate documents
>that conform to the DTDs of the present specification. The HTML
>Working Group reserves the right to correct known bugs.
>  * Software conforming to the DTDs of the present specification may
>ignore features of future HTML 4 DTDs that it does not recognize.
>
> This was also the case with earlier versions of HTML.
>
> regards,
>
> Derick Rethans
>
> -
> PHP: Scripting the Web - www.php.net - [EMAIL PROTECTED]
>  SRM: Site Resource Manager - www.vl-srm.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 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] Bug #11611 Updated: nl2br() outputting invalid tags

[lenar]

Uh, ok. I give up. I just wasn't able earlier to find this paragraph from spec.
Sorry if I disturbed you too much :)

lenar.

> Browsers should ignore things which they don't recognise:
> (from http://www.w3.org/TR/1999/REC-html401-19991224/html40.txt, paragraph
> 7.2)
> 
>Note. As of the 24 December version of HTML 4.01, the HTML Working
>Group commits to the following policy:
>  * Any changes to future HTML 4 DTDs will not invalidate documents
>that conform to the DTDs of the present specification. The HTML
>Working Group reserves the right to correct known bugs.
>  * Software conforming to the DTDs of the present specification may
>ignore features of future HTML 4 DTDs that it does not recognize.
> 
> This was also the case with earlier versions of HTML.
> 
> regards,
> 
> Derick Rethans



--
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] Bug #11611 Updated: nl2br() outputting invalid tags

[derick]

On Sun, 24 Jun 2001 [EMAIL PROTECTED] wrote:

> On Sun, 24 Jun 2001, [iso-8859-15] Lenar Lõhmus wrote:
>
> >
> > Yes, agree, but this change has happend not much time ago, and I think
> > it's one's responsibility to maintain the behavior what it used to
> > be. Even more if the old syntax was generating standard compliant code
> > (and HTML4 is a standard).
>
> This syntax is perfectly html 4.01 (transistional) compliant.
> (Try requesting this link through validator.w3.org:
> http://defiant.jdimedia.nl:7480/php-hacking/php11611.php (only works
> during night hours in GMT)

I just validated this same document with HTML 3.2 and 2.0, still perfectly
compliant. (The file is
http://defiant.jdimedia.nl:7480/php-hacking/php11611b.php) (HTML 2.0
doctype).

regards,

Derick Rethans

-
PHP: Scripting the Web - www.php.net - [EMAIL PROTECTED]
 SRM: Site Resource Manager - www.vl-srm.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] cvs.php.net downtime

[Sascha Schumann]

As part of a facility change, cvs.php.net might be unavailable
from 25th June 22:00 CEST until 05:00 CEST (16:00-23:00 EST).

- 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]

Re: [PHP-DEV] About ext/sockets/

[Sascha Schumann]

Jeroen,

> For lower-scale and home-use you can argue it is easier
> than *nix. So when possible, you should try to support windows.
[..]
> > [looked like C, was easier for ppl with C-background]
>
> I don't think you should target php at C-ppl.

PHP has been since its inception strongly influenced by C.
And as a tool originally conceived on Unix, it should
maintain its roots and continue to provide people familiar
with Unix APIs a convenient way for scripting.

Thus, improved Windows support should not come at the expense
of Unix support without a perfect reason.  I'm missing that
reason here.

I haven't looked deeply at what API changes have been
introduced lately, but I'd suggest to use the standard BSD
sockets return value semantics (-1 for failure, >= 0 for
success).  Those semantics also prevail in the Winsock
implementation, so they should be quite natural.

- 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] Bug #11057 Updated: Premature end of script headers: c:/php/php.exe

[baret]

ID: 11057
User Update by: [EMAIL PROTECTED]
Status: Closed
Bug Type: ODBC related
Operating system: Windows 98 SE
PHP Version: 4.0.4
Description: Premature end of script headers: c:/php/php.exe

Im sorry. It means, that i see windows error, that there is an error in php.exe. Web 
server is still working, but in the log file is written aboud premature ending of 

No HTML page is shown.

Previous Comments:
---

[2001-06-21 11:23:49] [EMAIL PROTECTED]
no user feedback.  please reopen the bug if you're still having trouble.

---

[2001-06-01 13:49:08] [EMAIL PROTECTED]
when you say it crashes what exactly does that mean?  do you still see the web server 
working and that message came up?  or did you get a nice core dump to show up with 
that statement on the screen popup?

---

[2001-05-26 03:55:18] [EMAIL PROTECTED]
OK, here is the part of the script. Btw. i found, that this appears only if in query 
is agregate function count(*) (there are two types of query, one works good, other 
not)
Im using MySQL 3.23.27-beta with MyODBC driver. There is table tab01 with information 
about clients.
Script:



Welcome






Login: 








---

[2001-05-25 10:03:06] [EMAIL PROTECTED]
this really doesn't sound like a PHP problem to me.  you said it yourself when "using 
normal ODBC_functions everything is alright" (grammer corrected).  

regardless of that, if you're still convinced this is a PHP ODBC error, give me a 
SIMPLE sample script that i can use to reproduce this (about 10 lines or so), and what 
database you're using.

---

[2001-05-23 12:41:12] [EMAIL PROTECTED]
I probably recognized the problem, my scripts generates sql queries like this 
(non-problematic version):

$query = "select count(*) cnt from tab01, tab11 where login='"
.$login.
"' and tab01.client_id = tab11.client_id and passwd=password('".$psswd."')";

I changed, so it should not be case sensitive for "login".

$query = "select count(*) cnt from tab01, tab11 where login='"
.strtolower($login).
"' and tab01.client_id = tab11.client_id and passwd=password('".$psswd."')";

but this didnt work, i tried also to convert to lowercase before using the converted 
string and that was also wrong.

$login = strtolower($login);

and then i used the first query.

So when I dont use converted strings, my functions works good, but when I use them, 
there is a problem described above.

---

The remainder of the comments for this report are too long.  To view the rest of the 
comments, please view the bug report online.

Full Bug description available at: http://bugs.php.net/?id=11057


-- 
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] About ext/sockets/

[Lukas Beeler]

> -Original Message-
> From: sterling hughes [mailto:[EMAIL PROTECTED]] 
> Sent: Sunday, June 24, 2001 9:49 PM
> To: Lukas Beeler
> Cc: [EMAIL PROTECTED]
> Subject: RE: [PHP-DEV] About ext/sockets/
> 
> 
> On 24 Jun 2001 21:40:19 +0200, Lukas Beeler wrote:
> > 
> > 
> > > -Original Message-
> > > From: [EMAIL PROTECTED] 
> > > [mailto:[EMAIL PROTECTED]] On Behalf Of Jani Taskinen
> > > Sent: Sunday, June 24, 2001 9:11 PM
> > > To: Daniel Beulshausen
> > > Cc: [EMAIL PROTECTED]
> > > Subject: Re: [PHP-DEV] About ext/sockets/ 
> > > 
> > > 
> > > On Sun, 24 Jun 2001, Daniel Beulshausen wrote:
> > > 
> > > >the issue that made the extension break was the step from 
> > > resources to
> > > >longs for the socket fd's, this was necessary as win32 
> > > socket fd's are
> > > >different from bsd style socket fd's.
> > > 
> > > So this is broken now only on *nix? Nice.
> > > Previously it worked only on unices, now it works only on win32?
> > > What an improvement.
> > it isn't broken, i've just compiled the latest cvs, and the 
> > "new" sockets example script performed well, also with using
> > pcntl to fork the "servers"
> > 
> 
> well, it depends what you consider broken, when the extension was
> commited, parts of it (*nix) were accessing integers like they were
> structures... I've gone through the source code and will be committing
> improvements, today or tommorow (i hope), there are a few functions
> which are "broken".
> 
> -Sterling
of course it always depends on how you define broken
as already said, i would classify it "experimental" and leave the "old"
sockets extension
as it is in upcoming releases till completion of the "new" sockets
extension

Lukas Beeler


-- 
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] Bug #11645 Updated: tempnam( ) does not use TMP environment variable

[lenar]

<[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> ID: 11645
> Updated by: sniper
> Reported By: [EMAIL PROTECTED]
> Old-Status: Open
> Status: Analyzed
> Old-Bug Type: Filesystem function related
> Bug Type: Documentation problem
> Operating system: 
> PHP Version: 4.0.6
> Assigned To: 
> Comments:
> 
> This is documentation problem. The given path takes precedence over TMPDIR 
>environment variable (not TMP environment variable as it is in docs)
This should be platform dependent. On Win32 it's usually TEMP (or TMP too with later 
wdozes) environment variable which specifies the location of directory for temporary 
files.
TMPDIR is used on linux (maybe other *nix too, don't know - propably).

This is suggestion for implementation/documentation change.

lenar.

> 
> From php4/main/php_open_temporary_file.c:
> 
> /* {{{ php_open_temporary_file
>  *
>  * Unlike tempnam(), the supplied dir argument takes precedence
>  * over the TMPDIR environment variable
>  * This function should do its best to return a file pointer to a newly created
>  * unique file, on every platform.
>  */
> 
> This makes the function behave the same way on every system.
> 
> 
> Previous Comments:
> ---
> 
> [2001-06-24 14:17:51] [EMAIL PROTECTED]
> The PHP manual states:
> 
> The behaviour of the tempnam() function is system dependent. On Windows the TMP 
>environment variable will override the dir parameter.
> 
> However testing the following when my TMP env variable is set to WINDOWSTMP:
> 
>   print tempnam('/','z')
> 
> the result is:
> 
>   C:zB312.TMP
> 
> This used to work fine in PHP 4.0.4pl1.
> 
> Thanks again, John
> 
> 
> 
> 
> ---
> 
> 
> 
> ATTENTION! Do NOT reply to this email!
> To reply, use the web interface found at http://bugs.php.net/?id=11645&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 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] Bug #11611 Updated: nl2br() outputting invalid tags

[derick]

On Sun, 24 Jun 2001, [iso-8859-15] Lenar Lõhmus wrote:

>
> Yes, agree, but this change has happend not much time ago, and I think
> it's one's responsibility to maintain the behavior what it used to
> be. Even more if the old syntax was generating standard compliant code
> (and HTML4 is a standard).

This syntax is perfectly html 4.01 (transistional) compliant.
(Try requesting this link through validator.w3.org:
http://defiant.jdimedia.nl:7480/php-hacking/php11611.php (only works
during night hours in GMT)

>
> Still, we must evolve, so a syntax like
> nl2br(string text [boolean html4]) would give the most up to date
> behaviour of this function, giving somebody an option to get the old
> behaviour when it's really neccessary.

It is never neccesary, unless Microsoft (or any other) wrote a browser
that is not adhering to the standards.

>
> And ... you don't know a browser where  dowsn't work? But there
> might be one ... one's own specific implementation where creator haven't
> thought up possibility that "" might be "" one day. Since it is
> not neccessary for HTML to recognize "/" in the end of single tag then we
> can't really blame him.

Browsers should ignore things which they don't recognise:
(from http://www.w3.org/TR/1999/REC-html401-19991224/html40.txt, paragraph
7.2)

   Note. As of the 24 December version of HTML 4.01, the HTML Working
   Group commits to the following policy:
 * Any changes to future HTML 4 DTDs will not invalidate documents
   that conform to the DTDs of the present specification. The HTML
   Working Group reserves the right to correct known bugs.
 * Software conforming to the DTDs of the present specification may
   ignore features of future HTML 4 DTDs that it does not recognize.

This was also the case with earlier versions of HTML.

regards,

Derick Rethans

-
PHP: Scripting the Web - www.php.net - [EMAIL PROTECTED]
 SRM: Site Resource Manager - www.vl-srm.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] Bug #11645 Updated: tempnam( ) does not use TMP environment variable

[sniper]

ID: 11645
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Analyzed
Old-Bug Type: Filesystem function related
Bug Type: Documentation problem
Operating system: 
PHP Version: 4.0.6
Assigned To: 
Comments:

This is documentation problem. The given path takes precedence over TMPDIR environment 
variable (not TMP environment variable as it is in docs)

>From php4/main/php_open_temporary_file.c:

/* {{{ php_open_temporary_file
 *
 * Unlike tempnam(), the supplied dir argument takes precedence
 * over the TMPDIR environment variable
 * This function should do its best to return a file pointer to a newly created
 * unique file, on every platform.
 */

This makes the function behave the same way on every system.


Previous Comments:
---

[2001-06-24 14:17:51] [EMAIL PROTECTED]
The PHP manual states:

The behaviour of the tempnam() function is system dependent. On Windows the TMP 
environment variable will override the dir parameter.

However testing the following when my TMP env variable is set to WINDOWSTMP:

  print tempnam('/','z')

the result is:

  C:zB312.TMP

This used to work fine in PHP 4.0.4pl1.

Thanks again, John




---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=11645&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 #10828 Updated: sometimes get_extension_funcs() kills PHP

[jo]

ID: 10828
User Update by: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Open
Bug Type: PHP options/info functions
Operating system: Linux 2.4.5
PHP Version: 4.0.6
Description: sometimes get_extension_funcs() kills PHP

Ok, I spend a sunday with wounderful weather about this 
and finally isolated the bug:
get_loaded_extensions() returns an extension called 
"Session MM" when available.
Feeding this string to get_extension_funcs() kills the 
process. So the simpliest way to reprodruce the bug is:

Most probably this works only when the extension is 
available, that would explain why some people had no 
problem running the example.
HTH, Jo


Previous Comments:
---

[2001-06-24 11:32:20] [EMAIL PROTECTED]
Does it crash? Provide a GDB backtrace then.
(reconfigure/compile PHP first with --enable-debug)

Remember to delete config.cache before configure.
And do 'make clean' after.

--Jani


---

[2001-06-24 10:25:36] [EMAIL PROTECTED]
Sorry, but he same in PHP4.0.6


---

[2001-06-10 21:25:40] [EMAIL PROTECTED]
No feedback. Closing.

- James

---

[2001-05-14 08:37:45] [EMAIL PROTECTED]
Your script works for me just fine with PHP 4.0.6-dev.
Please try latest snapshot from http://snaps.php.net/

--Jani




---

[2001-05-12 08:32:35] [EMAIL PROTECTED]
I tried to print out all available PHP functions using 
get_loaded_extensions() and get_extension_funcs():
PHP" . phpversion() . "n");
print("n");
$ext = get_loaded_extensions();
sort($ext);
for($i = 0; $i < count($ext); $i++) {
$name = $ext[$i];
print("$name:nn");
$func = get_extension_funcs($name);
sort($func);
for($j = 0; $j < count($func); $j++) {

print("$func[$j]()n");
}
print("n");
}
print("n");
?>
and this worked well with PHP4.0.3pl1.
However, since PHP4.0.4pl1/5, the Apache (1.3.19) 
subprocess dies:
[Sat May 12 14:26:49 2001] [notice] child pid 746 exit 
signal Segmentation fault (11)
When commenting out the get_extension_funcs() call, all is 
well. Even replacing the argument to a const (eg. 
get_extension_funcs("exif") ) works.
I tried to reproduce the error in a more simple way, but 
failed:

works as expected. Still the script above fails.


---

The remainder of the comments for this report are too long.  To view the rest of the 
comments, please view the bug report online.

Full Bug description available at: http://bugs.php.net/?id=10828


-- 
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 #11642 Updated: mcrypt_generic() leaks memory

[derick]

ID: 11642
Updated by: derick
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Assigned
Bug Type: mcrypt related
Operating system: 
PHP Version: 4.0.6
Assigned To: derick
Comments:

I'll check this out

Previous Comments:
---

[2001-06-24 12:17:53] [EMAIL PROTECTED]
Minimal configuration

./configure  --without-mysql --with-apache=../apache_1.3.20 --without-gd 
--without-zlib --without-gdbm
--without-shared-apache --with-mcrypt

libmcrypt versions 2.2.7, 2.4.10, 2.4.11, 2.4.15
php versions 4.0.4pl1, 4.0.5, 4.0.6

This script leaks about 6MB per execution on my system.


encrypt($input);
$x = $CBC->decrypt($block);

if ($x != $input)
print "$xn";
?>


Modifying PEAR/Crypt/CBC.php to use mcrypt_ecb() instead of
mcrypt_generic() reduces memory leak to less than 1MB
after 1000 executions.




---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=11642&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]

Re: [PHP-DEV] About ext/sockets/

[jeroen]

> [don't break the API!]

> >i'd vote not for changing the api back, rather than
> updating/extending the
> >yet available (tiny) sockets documentation.
>
> I vote we get the old api back. I don't care if it doesn't
> support win32.

1) IMHO the new API is better (the 'write' function is really a name someone
wants to use for other things...), and the new return-values are more logic.
This does NOT mean that I think you should break the current API!
2) Undoubtly Daniel has put quite some effort in making this
extension work for windows. I don't think it's really
necessary to burn him down. I know, windows is not a
platform for the serious sites, but you cannot deny it is used
alot. (though I think it will change with XP - eXtra Pricy :-)
For lower-scale and home-use you can argue it is easier
than *nix. So when possible, you should try to support windows.

3) I'm certain that there is a way to merge the *nix and windows
implementations, so that it works on both platforms. As I
stated in an earlier post, i think it is possible to support
both API's.


As a short-term solution i'd suggest to put the current session.c
in #ifdef PHP_WIN32 / #endif, and put the old one
(that worked for unix) in #ifndef PHP_WIN32.

As a longer term solution, either a wrapper API should
be added to the unix-variant, to comply with the 'win32'
API, or (better, but probably harder) the current sockets.c
should be fixed to work for unix too. (and there should
be functions for BC, that simply call the new ones).

In a reply to the just arrived mail of Daniel:
> this shouldn't mean that every function in php should behave like the c
> counterpart, should it?
> if we have the possibility to do something in a more userfriendly fashion
i
> think it should be done that way.

I agree on this one.

> i don't think that the translation to the new api is too hard.

Well, it probably isn't, but keep in mind that not everybody
has control over which php is installed and when it is updated.
And why break BC when it is not necessary?

Jani wrote:
> [looked like C, was easier for ppl with C-background]

I don't think you should target php at C-ppl.


Greetz,
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] About ext/sockets/

[sterling hughes]

On 24 Jun 2001 21:40:19 +0200, Lukas Beeler wrote:
> 
> 
> > -Original Message-
> > From: [EMAIL PROTECTED] 
> > [mailto:[EMAIL PROTECTED]] On Behalf Of Jani Taskinen
> > Sent: Sunday, June 24, 2001 9:11 PM
> > To: Daniel Beulshausen
> > Cc: [EMAIL PROTECTED]
> > Subject: Re: [PHP-DEV] About ext/sockets/ 
> > 
> > 
> > On Sun, 24 Jun 2001, Daniel Beulshausen wrote:
> > 
> > >the issue that made the extension break was the step from 
> > resources to
> > >longs for the socket fd's, this was necessary as win32 
> > socket fd's are
> > >different from bsd style socket fd's.
> > 
> > So this is broken now only on *nix? Nice.
> > Previously it worked only on unices, now it works only on win32?
> > What an improvement.
> it isn't broken, i've just compiled the latest cvs, and the 
> "new" sockets example script performed well, also with using
> pcntl to fork the "servers"
> 

well, it depends what you consider broken, when the extension was
commited, parts of it (*nix) were accessing integers like they were
structures... I've gone through the source code and will be committing
improvements, today or tommorow (i hope), there are a few functions
which are "broken".

-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] Internal Working -- performance question

[lenar]

I don't know if MySQL supports HEAP tables under Win32 but otherwise I suggest using 
them for IPC in your PHP applications.
We use it, and so far it has worked great for us (very good perfomance) using it 
combined with mysql_pconnect().

Lenar

""James Moore"" <[EMAIL PROTECTED]> wrote in message 
000f01c0fbcb$e522a640$010a@zeus">news:000f01c0fbcb$e522a640$010a@zeus...
> > a) Is there a faster way to send data between 2 processes, 
> > that will work with PHP, and is supported by Windows and *nix.
> 
> How about abstacting it, under Linux use shared mem (should be fastest)
> if its avalible, other wise use sockets then If that's not avalible use
> database/file version.
> 
> - James
> 
> 
> -- 
> 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]

RE: [PHP-DEV] About ext/sockets/

[Lukas Beeler]

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]] On Behalf Of Jani Taskinen
> Sent: Sunday, June 24, 2001 9:11 PM
> To: Daniel Beulshausen
> Cc: [EMAIL PROTECTED]
> Subject: Re: [PHP-DEV] About ext/sockets/ 
> 
> 
> On Sun, 24 Jun 2001, Daniel Beulshausen wrote:
> 
> >the issue that made the extension break was the step from 
> resources to
> >longs for the socket fd's, this was necessary as win32 
> socket fd's are
> >different from bsd style socket fd's.
> 
> So this is broken now only on *nix? Nice.
> Previously it worked only on unices, now it works only on win32?
> What an improvement.
it isn't broken, i've just compiled the latest cvs, and the 
"new" sockets example script performed well, also with using
pcntl to fork the "servers"


> >as this change would already have broken the extension i 
> decided to update
> >the api as well, mainly the functions names, but also some 
> return types.
> 
> Did you happen to think that maybe people have already got used to the
> way it works? And they have created lot of scripts depending on the
> old behaviour? Old behaviour was also consistent with how the 
> low-level
> socket functions worked. Which makes it easier to those people who
> already know socket programming in C to use this extension.
yes, the renaming confused me first, and still after renaming the
example script,
it didn't work. i had to use a new example script
i don't think, that this is a good solution
maybe two "socket" module would be one ?

> >the extension works pretty well under win32 now, but if 
> there are functions
> >that are broken under posix i suggest that someone with more 
> knowledge of
> >the bsd sockets than i has a look at them.
> 
> Maybe you shouldn't have touched it at all then?
> You should have sent the patch first to the list.
> And after someone using *nix platform had tested and verified 
> it really
> worked only after that you should have committed.
> 
> Never heard this: 'test before commit' ???
i agree

> >i'd vote not for changing the api back, rather than 
> updating/extending the
> >yet available (tiny) sockets documentation.
> 
> I vote we get the old api back. I don't care if it doesn't 
> support win32.
who cares about win32 ? ;)
> Document that instead. Or update the documentation then. And 
> add working
> examples there. I'm not gonna waste my time trying to figure out this.
i agree
> 
> --Jani
Lukas Beeler
> 
> 
> 
> 
> -- 
> 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]

Re: [PHP-DEV] Bug #11611 Updated: nl2br() outputting invalid tags

[lenar]

"Derick Rethans" <[EMAIL PROTECTED]> wrote in message 
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> On Fri, 22 Jun 2001, lenar wrote:
> 
> > Shouldn't there be an optional flag to nl2br to change the behavior of function to 
>what it used to be.
> > Just there's no point in  like tags when the rest of your code is just 
>generating HTML compliant output,
> > not XHTML.
> 
>  is HTML compliant too, and there is no single browser who doesn't
> get it.

But it's not the behaviour up to today of this function. And I suggested only optional 
flag for getting old behavior.
Like nl2br(string text [boolean html]).

And to avoid rest, I say it more clearly: I agree it should generate XHTML 
_by_default_.

lenar
> 



--
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] Bug #11611 Updated: nl2br() outputting invalid tags

[Lenar Lõhmus]

> > when the rest of your code is just generating HTML compliant output, not
> > XHTML.
> > 
> > Ok, somebody can always use something like str_replace("\n", "",
> > $text) to get the old functionality.
> 
> What if the rest of your code is generating XHTML?  It's better to assume
> the more strict syntax, especially considering that nobody has yet found (to
> my knowledge) a browser where  doesn't work.
> 
Yes, agree, but this change has happend not much time ago, and I think
it's one's responsibility to maintain the behavior what it used to
be. Even more if the old syntax was generating standard compliant code
(and HTML4 is a standard).  

Still, we must evolve, so a syntax like
nl2br(string text [boolean html4]) would give the most up to date
behaviour of this function, giving somebody an option to get the old
behaviour when it's really neccessary.

And ... you don't know a browser where  dowsn't work? But there
might be one ... one's own specific implementation where creator haven't
thought up possibility that "" might be "" one day. Since it is
not neccessary for HTML to recognize "/" in the end of single tag then we
can't really blame him.

lenar.

> Matt
> 


-- 
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] About ext/sockets/

[Daniel Beulshausen]

At 21:10 24.06.2001 +0200, Jani Taskinen wrote:
>On Sun, 24 Jun 2001, Daniel Beulshausen wrote:
>
> >the issue that made the extension break was the step from resources to
> >longs for the socket fd's, this was necessary as win32 socket fd's are
> >different from bsd style socket fd's.
>
>So this is broken now only on *nix? Nice.
>Previously it worked only on unices, now it works only on win32?
>What an improvement.

i didn't say it's broken, and no i don't use linux...

> >as this change would already have broken the extension i decided to update
> >the api as well, mainly the functions names, but also some return types.
>
>Did you happen to think that maybe people have already got used to the
>way it works? And they have created lot of scripts depending on the
>old behaviour? Old behaviour was also consistent with how the low-level
>socket functions worked. Which makes it easier to those people who
>already know socket programming in C to use this extension.

this shouldn't mean that every function in php should behave like the c 
counterpart, should it?
if we have the possibility to do something in a more userfriendly fashion i 
think it should be done that way.
yes, the new extension breaks backwards capability for advantage of not 
running only under linux.
and who says that and extension should stay it was in it initial revision?
i don't think that the translation to the new api is too hard.

> >the extension works pretty well under win32 now, but if there are functions
> >that are broken under posix i suggest that someone with more knowledge of
> >the bsd sockets than i has a look at them.
>
>Maybe you shouldn't have touched it at all then?
>You should have sent the patch first to the list.
>And after someone using *nix platform had tested and verified it really
>worked only after that you should have committed.
>
>Never heard this: 'test before commit' ???

it was send to this list, and voices said it's ok to commit...

daniel

> >i'd vote not for changing the api back, rather than updating/extending the
> >yet available (tiny) sockets documentation.
>
>I vote we get the old api back. I don't care if it doesn't support win32.
>Document that instead. Or update the documentation then. And add working
>examples there. I'm not gonna waste my time trying to figure out this.

/*--
daniel beulshausen - [EMAIL PROTECTED]
searching job: application development with php
using php on windows? http://www.php4win.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] creating a new extension

[Julia A. Case]

I want to create a new extension that is a wrapper for the 
libfalken.so.12.0 shared library, I don't and can't get source code for 
it.  I tried a very simple experiment where I just called the init() 
function (this sets up the initial variables and such) but when I call it 
I get a segfault in php...  The core file shows this

Cannot create references to/from string offsets nor overloaded objects

If you need more of the core file, I can provide that, any help is 
appreciated.

Thanks,
Julia

-- 
[  Julia Anne Case  ] [Ships are safe inside the harbor,   ]
[Programmer at large] [  but is that what ships are really for.]  
[   Admining Linux  ] [   To thine own self be true.   ]
[ Windows/WindowsNT ] [ Fair is where you take your cows to be judged. ]
  

-- 
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] About ext/sockets/

[Jani Taskinen]

On Sun, 24 Jun 2001, Daniel Beulshausen wrote:

>the issue that made the extension break was the step from resources to
>longs for the socket fd's, this was necessary as win32 socket fd's are
>different from bsd style socket fd's.

So this is broken now only on *nix? Nice.
Previously it worked only on unices, now it works only on win32?
What an improvement.

>as this change would already have broken the extension i decided to update
>the api as well, mainly the functions names, but also some return types.

Did you happen to think that maybe people have already got used to the
way it works? And they have created lot of scripts depending on the
old behaviour? Old behaviour was also consistent with how the low-level
socket functions worked. Which makes it easier to those people who
already know socket programming in C to use this extension.

>the extension works pretty well under win32 now, but if there are functions
>that are broken under posix i suggest that someone with more knowledge of
>the bsd sockets than i has a look at them.

Maybe you shouldn't have touched it at all then?
You should have sent the patch first to the list.
And after someone using *nix platform had tested and verified it really
worked only after that you should have committed.

Never heard this: 'test before commit' ???

>i'd vote not for changing the api back, rather than updating/extending the
>yet available (tiny) sockets documentation.

I vote we get the old api back. I don't care if it doesn't support win32.
Document that instead. Or update the documentation then. And add working
examples there. I'm not gonna waste my time trying to figure out this.

--Jani




-- 
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] About ext/sockets/

[Daniel Beulshausen]

At 20:58 24.06.2001 +0200, Daniel Beulshausen wrote:
>jani,
>
>At 20:21 24.06.2001 +0200, Jani Taskinen wrote:
>
>>What new functionality? Why the hell should the API change?
>>Only the function names should have been changed, not break
>>the whole extension!
>
>the issue that made the extension break was the step from resources to 
>longs for the socket fd's, this was necessary as win32 socket fd's are 
>different from bsd style socket fd's.
>as this change would already have broken the extension i decided to update 
>the api as well, mainly the functions names, but also some return types.
>if the actual behaviour is unwanted it should be changed, i myself find 
>the api now much more useable (userfriendly).
>the extension works pretty well under win32 now, but if there are 
>functions that are broken under posix i suggest that someone with more 
>knowledge of the bsd sockets than i has a look at them.
>i'd vote not for changing the api back, rather than updating/extending the 
>yet available (tiny) sockets documentation.

you should have read "but updating..."

daniel

>daniel
>
>>--Jani
>>
>>
>>On Sun, 24 Jun 2001, Andi Gutmans wrote:
>>
>> >Maybe we should wait with this whole API change until a new sub-version?
>> >4.1? Or keep the old functionality right now and just add the new
>> >functions? We can deprecate the old ones in 4.1.
>> >
>> >Andi
>> >
>> >At 03:03 PM 6/24/2001 +0200, Jani Taskinen wrote:
>> >
>> >>Since everybody seems to be using some stupid filters which filters
>> >>all emails which have 'Bug' in the Subject I have to mail this again..
>> >>(Hint: There is X-PHP-Bug: header in those emails that come from bug 
>> system)
>> >>
>> >>Anyway, we have a problem. The sockets extension is seriously fucked up
>> >>now. Some functions don't work at all and some work differently than
>> >>before the renaming of the function names. ie. they return FALSE
>> >>on errors now..before they returned -1. Good example: socket_listen()
>> >>
>> >>This is really bad thing and breaks every single script out there
>> >>which uses these functions. It would be acceptable that the function
>> >>names only needed to be changed, but now there has to be really big
>> >>changes in the whole logic the scripts work.
>> >>
>> >>(even our example scripts on manual don't work)
>> >>
>> >>--Jani
>> >>
>> >>
>> >>On 22 Jun 2001 [EMAIL PROTECTED] wrote:
>> >>
>> >> >From: [EMAIL PROTECTED]
>> >> >Operating system: Slackware-current / Kernel 2.4.5
>> >> >PHP version:  4.0 Latest CVS (2001-06-22)
>> >> >PHP Bug Type: Sockets related
>> >> >Bug description:  Socket function examples scripts aren't working with
>> >> latest CVS
>> >> >
>> >> >After checking the renamed socket functions, i tried to get the sockets
>> >> >example script running. It works fine under 4.0.5, so i renamed the
>> >> >functions to the new ones, und tried to get it running. It started, 
>> and i
>> >> >could connect without problems, but instead of being an echo server, i
>> >> >just got disconnectet.
>> >> >When are the new sockets function getting documented with an example
>> >> script ?
>> >> >thx in advance
>> >>
>> >>
>> >>--
>> >>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]
>> >
>
>
>/*--
>daniel beulshausen - [EMAIL PROTECTED]
>searching job: application development with php
>using php on windows? http://www.php4win.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]

/*--
daniel beulshausen - [EMAIL PROTECTED]
searching job: application development with php
using php on windows? http://www.php4win.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]

Re: [PHP-DEV] About ext/sockets/

[jeroen]

> > Because of the experimental status, I don't think phpdev should worry
too
> > much about the
> > incompatibility, it's the user's own reponsibility to use an
experimental
> > module.
>
> Taking a look at the changes to the sockets extension, some break things
> on a Linux system, some don't work at all,
If I understand you well (I'm not sure I do), you say that the new extension
doesn't work properly on linux? Of course, that needs to be fixed...
but the new API seems fine by me.

> a side note even with
> experimental extensions, you still need to be concerned with backwards
> compatibility, under your logic i could remove the Sablotron extension
> in favor of the XSLT extension, since Sablotron is marked experimental?

No, I was a bit un-nuancated (I hope you understand that dutch-ism...).
You're right, above that, the fact it is experimental wasn't stated in
the documentation. Though IMO in experimental does mean that the
API might change. Of course, try to keep the old scripts working, but
if a choice has to made between either a consequent API and 100%BC
and an inconsequent API with 95% BC... I think the consequent API
is preferred. Otherwise you'll sit for ages with a strange API.

Summary:: Change the API when the module is still in experimental status,
rather than never change it and sit with a bad API for long time.
But this discussion is not relevant here, because it's possible to
both change API and keep old scripts working. (see below)

> I wouldn't remove the EXPERIMENTAL status.
k

Jani wrote:
> What new functionality? Why the hell should the API change?
> Only the function names should have been changed, not break
> the whole extension!

I am in favor of the change to follow the convention of returning
FALSE on error. It can be combined with the function-renaming:
let the old function names behave - for now - as before, but
let the new ones behave the new way. I.e.: do NOT let the
new names be aliases for the old ones. This way you
won't break current scripts, while the new API is still compliant
to the current PHP-conventions.

Greetz,
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] About ext/sockets/

[Daniel Beulshausen]

jani,

At 20:21 24.06.2001 +0200, Jani Taskinen wrote:

>What new functionality? Why the hell should the API change?
>Only the function names should have been changed, not break
>the whole extension!

the issue that made the extension break was the step from resources to 
longs for the socket fd's, this was necessary as win32 socket fd's are 
different from bsd style socket fd's.
as this change would already have broken the extension i decided to update 
the api as well, mainly the functions names, but also some return types.
if the actual behaviour is unwanted it should be changed, i myself find the 
api now much more useable (userfriendly).
the extension works pretty well under win32 now, but if there are functions 
that are broken under posix i suggest that someone with more knowledge of 
the bsd sockets than i has a look at them.
i'd vote not for changing the api back, rather than updating/extending the 
yet available (tiny) sockets documentation.

daniel

>--Jani
>
>
>On Sun, 24 Jun 2001, Andi Gutmans wrote:
>
> >Maybe we should wait with this whole API change until a new sub-version?
> >4.1? Or keep the old functionality right now and just add the new
> >functions? We can deprecate the old ones in 4.1.
> >
> >Andi
> >
> >At 03:03 PM 6/24/2001 +0200, Jani Taskinen wrote:
> >
> >>Since everybody seems to be using some stupid filters which filters
> >>all emails which have 'Bug' in the Subject I have to mail this again..
> >>(Hint: There is X-PHP-Bug: header in those emails that come from bug 
> system)
> >>
> >>Anyway, we have a problem. The sockets extension is seriously fucked up
> >>now. Some functions don't work at all and some work differently than
> >>before the renaming of the function names. ie. they return FALSE
> >>on errors now..before they returned -1. Good example: socket_listen()
> >>
> >>This is really bad thing and breaks every single script out there
> >>which uses these functions. It would be acceptable that the function
> >>names only needed to be changed, but now there has to be really big
> >>changes in the whole logic the scripts work.
> >>
> >>(even our example scripts on manual don't work)
> >>
> >>--Jani
> >>
> >>
> >>On 22 Jun 2001 [EMAIL PROTECTED] wrote:
> >>
> >> >From: [EMAIL PROTECTED]
> >> >Operating system: Slackware-current / Kernel 2.4.5
> >> >PHP version:  4.0 Latest CVS (2001-06-22)
> >> >PHP Bug Type: Sockets related
> >> >Bug description:  Socket function examples scripts aren't working with
> >> latest CVS
> >> >
> >> >After checking the renamed socket functions, i tried to get the sockets
> >> >example script running. It works fine under 4.0.5, so i renamed the
> >> >functions to the new ones, und tried to get it running. It started, and i
> >> >could connect without problems, but instead of being an echo server, i
> >> >just got disconnectet.
> >> >When are the new sockets function getting documented with an example
> >> script ?
> >> >thx in advance
> >>
> >>
> >>--
> >>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]
> >


/*--
daniel beulshausen - [EMAIL PROTECTED]
searching job: application development with php
using php on windows? http://www.php4win.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]

Re: [PHP-DEV] About ext/sockets/

[Jani Taskinen]

What new functionality? Why the hell should the API change?
Only the function names should have been changed, not break
the whole extension!

--Jani


On Sun, 24 Jun 2001, Andi Gutmans wrote:

>Maybe we should wait with this whole API change until a new sub-version?
>4.1? Or keep the old functionality right now and just add the new
>functions? We can deprecate the old ones in 4.1.
>
>Andi
>
>At 03:03 PM 6/24/2001 +0200, Jani Taskinen wrote:
>
>>Since everybody seems to be using some stupid filters which filters
>>all emails which have 'Bug' in the Subject I have to mail this again..
>>(Hint: There is X-PHP-Bug: header in those emails that come from bug system)
>>
>>Anyway, we have a problem. The sockets extension is seriously fucked up
>>now. Some functions don't work at all and some work differently than
>>before the renaming of the function names. ie. they return FALSE
>>on errors now..before they returned -1. Good example: socket_listen()
>>
>>This is really bad thing and breaks every single script out there
>>which uses these functions. It would be acceptable that the function
>>names only needed to be changed, but now there has to be really big
>>changes in the whole logic the scripts work.
>>
>>(even our example scripts on manual don't work)
>>
>>--Jani
>>
>>
>>On 22 Jun 2001 [EMAIL PROTECTED] wrote:
>>
>> >From: [EMAIL PROTECTED]
>> >Operating system: Slackware-current / Kernel 2.4.5
>> >PHP version:  4.0 Latest CVS (2001-06-22)
>> >PHP Bug Type: Sockets related
>> >Bug description:  Socket function examples scripts aren't working with
>> latest CVS
>> >
>> >After checking the renamed socket functions, i tried to get the sockets
>> >example script running. It works fine under 4.0.5, so i renamed the
>> >functions to the new ones, und tried to get it running. It started, and i
>> >could connect without problems, but instead of being an echo server, i
>> >just got disconnectet.
>> >When are the new sockets function getting documented with an example
>> script ?
>> >thx in advance
>>
>>
>>--
>>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 #11645: tempnam( ) does not use TMP environment variable

[jlim]

From: [EMAIL PROTECTED]
Operating system: Windows ME
PHP version:  4.0.6
PHP Bug Type: Filesystem function related
Bug description:  tempnam( ) does not use TMP environment variable

The PHP manual states:

The behaviour of the tempnam() function is system dependent. On Windows the TMP 
environment variable will override the dir parameter.

However testing the following when my TMP env variable is set to \WINDOWS\TMP:

  print tempnam('/','z')

the result is:

  C:\zB312.TMP

This used to work fine in PHP 4.0.4pl1.

Thanks again, John





-- 
Edit Bug report at: http://bugs.php.net/?id=11645&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] Read a file into a string (RE: [PHP-DEV] Sablotron leaks)

[Brian Tanner]

Doesn't this do that?

$FilePointer=fopen($FileLocation,"r");
$_MyString.=fread($FilePointer,filesize ($FileLocation));
fclose($FilePointer);

Althought I guess this could suck memory pretty hard on large files, and you
guys want to get away from that...

-Brian


> Blah...  I see this a lot.  We should probably just relent and make a
> function that reads an entire file into a string.
Yes, please do :)




-- 
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 #11644: Interbase dll causes PWS ISAPI to die

[jlim]

From: [EMAIL PROTECTED]
Operating system: Windows ME
PHP version:  4.0.6
PHP Bug Type: InterBase related
Bug description:  Interbase dll causes PWS ISAPI to die

Upgraded from PHP 4.0.4pl1 to PHP 4.0.6. Did not modify my php.ini. 

After the upgrade, I ran a test script with phpinfo() to see if the upgrade worked, 
and PWS died immediately.

By commenting out my extensions one by one, I discovered the culprit was 
php_interbase.dll. With only that extension removed, everything works fine using ISAPI.

When I use CGI with interbase, everything works fine. Perhaps the interbase dll is not 
100% thread safe?

Thanks for reading this, John


-- 
Edit Bug report at: http://bugs.php.net/?id=11644&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] array_rand behavior

[Andrew Kirilenko]

Hello!

I was a little confused, while using array_rand first time...
Please, take a look at the following code:
--->
define("NUM", 2);
$keys = array_rand(array(0,1,2,3,4,5), NUM);
for ($i=0; $i < NUM; $i++)
echo $i ." - " . $keys[$i] . "";
<---

If NUM is greater then 1, everything is OK, but if it's equal to 1,
array_rand return not array, but a scalar! And it's necessary to write
special code, like the following:

--->
if (NUM == 1)
$keys[0] = array_rand(array(0,1,2,3,4,5), NUM); // or $keys[0] = rand(0,
count(array(0,1,2,3,4,5)) - 1);
else
$keys = array_rand(array(0,1,2,3,4,5), NUM);
<---

Any suggestions, how to make array_rand more flexible?

Best regards,
Andrew Kirilenko,
Seniour Programmer / System Administrator,
Internet Service.


-- 
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] Read a file into a string (RE: [PHP-DEV] Sablotron leaks)

[Marten Gustafsson]

> Blah...  I see this a lot.  We should probably just relent and make a
> function that reads an entire file into a string.
Yes, please do :)


Regards,
Marten.

ps.
This has been requested in #5008, #7213 and #8882.

-- 
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] Sablotron leaks

[Martin Jansen]

On Sun, 24 Jun 2001 10:32:06 -0700 (PDT), Rasmus Lerdorf wrote:

>> $xsl = join("", file("x.xsl"));
>
>Blah...  I see this a lot.  We should probably just relent and make a
>function that reads an entire file into a string.

+1

- 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]

Re: [PHP-DEV] Sablotron leaks

[Phil Driscoll]

On Sunday 24 June 2001 18:32, Rasmus Lerdorf wrote:
> > $xsl = join("", file("x.xsl"));
>
> Blah...  I see this a lot.  We should probably just relent and make a
> function that reads an entire file into a string.

Yes please!
-- 
Phil Driscoll

-- 
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] Sablotron leaks

[Sebastian Bergmann]

Rasmus Lerdorf wrote:
> Blah...  I see this a lot.  We should probably just relent and make a
> function that reads an entire file into a string.

  +1 :)

-- 
 sebastian bergmann[EMAIL PROTECTED]
   http://www.sebastian-bergmann.de

 Meet the PHP Project at LinuxTag, Booth 5.0.334/2 - http://phpinfo.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]

Re: [PHP-DEV] Sablotron leaks

[Rasmus Lerdorf]

> $xsl = join("", file("x.xsl"));

Blah...  I see this a lot.  We should probably just relent and make a
function that reads an entire file into a string.

-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]

Re: [PHP-DEV] Sablotron leaks

[Stanislav Malyshev]

sh>> I'd need to see your test script to give you an answer, that
sh>> repeat count does look nasty (with an FYI that I'm no longer
sh>> maintaining Sablot, as all my development efforts are now
sh>> focused on the XSLT extension..)

The script is pretty plain:



-- 
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 #11617 Updated: crash when restoring references

[sniper]

ID: 11617
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: *Session related
Operating system: 
PHP Version: 4.0 Latest CVS (2001-06-22)
Assigned To: 
Comments:

Closed then.


Previous Comments:
---

[2001-06-24 12:49:11] [EMAIL PROTECTED]
I've messed up something with my versions. Recompiled good and now it looks like it 
works fine. Sorry for confusion.

Zork



---

[2001-06-24 11:59:13] [EMAIL PROTECTED]
And the GDB backtrace is where? Please include it.


---

[2001-06-24 11:29:39] [EMAIL PROTECTED]
Tried, but php still changed. Maybe it is something with CVS (forgot to commit?), I've 
checked session.c revision and result was:

revision 1.213
date: 2001/06/21 18:46:25;  author: thies;  state: Exp;  lines: +31 -26

I've submitted this bug later.

Zork

---

[2001-06-23 17:34:50] [EMAIL PROTECTED]
Could you please try again? The fix wasn't ok, but now
it's been rewritten and should work.

If it still crashes, try to generate a gdb backtrace of
the crash. And thank you for helping!

--Jani
 

---

[2001-06-22 11:01:25] [EMAIL PROTECTED]
There is still problem in serialize/unserialize mechanism  used to restore session 
variables(after closing #8676 bug which was supoused to correct the problem). Here is 
simplest script I can produce that does apache segfault on my machine:

 frames = array();
}
};

class CError_handler {
var $msg_error;

function CError_handler() {
$this -> msg_error = new CMessage();
}
};

class CConnection_Table {
var $data;

function CConnection_table() {
$this -> data = array();
}

function mconnect($message,&$object,$method) {
$data[0] = &$object;
$data[1] = $method;
$this -> data[$message -> msg_id][] = $data;
}
};

class CMessage {
var $data;
var $msg_id;

function CMessage($data = 0) {
global $__CMSGID_NEXT;
$this -> msg_id = $__CMSGID_NEXT++;
$this -> data = $data;
}
};

function MCONNECT(&$message,&$obj_name,$method_name) {
global $__connection_table;
$__connection_table -> mconnect($message,$obj_name,$method_name);
};

session_start();
session_destroy();
$__connection_table = new CConnection_table;
session_register("__connection_table");

$screen = new Cscreen();
session_register("screen");

$error_handler = new CError_handler($screen);
MCONNECT($error_handler -> msg_error,$screen,"fatal_error");
session_register("error_handler");
echo "done";
exit();



---

The remainder of the comments for this report are too long.  To view the rest of the 
comments, please view the bug report online.


ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=11617&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]

Re: [PHP-DEV] Sablotron leaks

[sterling hughes]

On 24 Jun 2001 19:09:24 +0300, Stanislav Malyshev wrote:
> Wehn using Sablotron extension, I see the following leaks:
> 
> /home/frodo/php4/ext/sablot/sablot.c(1397) :  Freeing 0x083AF0FC (12
> bytes), script=test_xsl.php
> Last leak repeated 899 times
> /home/frodo/php4/ext/sablot/sablot.c(555) :  Freeing 0x083F11F4 (77
> bytes), script=test_xsl.php
> Last leak repeated 48 times
> 
> Anybody know where to fix them? Repeat count looks pretty nasty...
> -- 


I'd need to see your test script to give you an answer, that repeat
count does look nasty (with an FYI that I'm no longer maintaining
Sablot, as all my development efforts are now focused on the XSLT
extension..)

-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] About ext/sockets/

[sterling hughes]

On 24 Jun 2001 17:43:02 +0200, [EMAIL PROTECTED] wrote:
> The documentation has just been updated, stating that the sockets-module is
> still experimental.
> As has any module having an EXPERIMENTAL file in it's directory.
> 
> Because of the experimental status, I don't think phpdev should worry too
> much about the
> incompatibility, it's the user's own reponsibility to use an experimental
> module.
> 

Taking a look at the changes to the sockets extension, some break things
on a Linux system, some don't work at all, as a side note even with
experimental extensions, you still need to be concerned with backwards
compatibility, under your logic i could remove the Sablotron extension
in favor of the XSLT extension, since Sablotron is marked experimental?

> But, now it is renamed, I think the experimental status can be lifted? It
> makes a
> good impression to me how it is currently designed, I don't know whether it
> is
> pretty stable? Anyway, the documentation should first be updated.
> 

I wouldn't remove the EXPERIMENTAL status.

-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] Bug #11643: SID redefined

[zork]

From: [EMAIL PROTECTED]
Operating system: Linux
PHP version:  4.0 Latest CVS (2001-06-24)
PHP Bug Type: *Session related
Bug description:  SID redefined

session_destroy() and session_register() both defines the same symbol. When I set:

error_reporting = E_ALL

in php.ini file I got warning:

Warning: Constant sid already defined in 
/home/sites/home/users/zork/web/report/sid.php on line 5

in this saple code:



On web: http://biuro.pablosoft.com.pl/~zork/report/sid.php

Zork


-- 
Edit Bug report at: http://bugs.php.net/?id=11643&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 #11617 Updated: crash when restoring references

[zork]

ID: 11617
User Update by: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Open
Bug Type: *Session related
Operating system: Linux 2.2.16 (Cobalt Raq4)
PHP Version: 4.0 Latest CVS (2001-06-22)
Description: crash when restoring references

I've messed up something with my versions. Recompiled good and now it looks like it 
works fine. Sorry for confusion.

Zork



Previous Comments:
---

[2001-06-24 11:59:13] [EMAIL PROTECTED]
And the GDB backtrace is where? Please include it.


---

[2001-06-24 11:29:39] [EMAIL PROTECTED]
Tried, but php still changed. Maybe it is something with CVS (forgot to commit?), I've 
checked session.c revision and result was:

revision 1.213
date: 2001/06/21 18:46:25;  author: thies;  state: Exp;  lines: +31 -26

I've submitted this bug later.

Zork

---

[2001-06-23 17:34:50] [EMAIL PROTECTED]
Could you please try again? The fix wasn't ok, but now
it's been rewritten and should work.

If it still crashes, try to generate a gdb backtrace of
the crash. And thank you for helping!

--Jani
 

---

[2001-06-22 11:01:25] [EMAIL PROTECTED]
There is still problem in serialize/unserialize mechanism  used to restore session 
variables(after closing #8676 bug which was supoused to correct the problem). Here is 
simplest script I can produce that does apache segfault on my machine:

 frames = array();
}
};

class CError_handler {
var $msg_error;

function CError_handler() {
$this -> msg_error = new CMessage();
}
};

class CConnection_Table {
var $data;

function CConnection_table() {
$this -> data = array();
}

function mconnect($message,&$object,$method) {
$data[0] = &$object;
$data[1] = $method;
$this -> data[$message -> msg_id][] = $data;
}
};

class CMessage {
var $data;
var $msg_id;

function CMessage($data = 0) {
global $__CMSGID_NEXT;
$this -> msg_id = $__CMSGID_NEXT++;
$this -> data = $data;
}
};

function MCONNECT(&$message,&$obj_name,$method_name) {
global $__connection_table;
$__connection_table -> mconnect($message,$obj_name,$method_name);
};

session_start();
session_destroy();
$__connection_table = new CConnection_table;
session_register("__connection_table");

$screen = new Cscreen();
session_register("screen");

$error_handler = new CError_handler($screen);
MCONNECT($error_handler -> msg_error,$screen,"fatal_error");
session_register("error_handler");
echo "done";
exit();



---


Full Bug description available at: http://bugs.php.net/?id=11617


-- 
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 #11642: mcrypt_generic() leaks memory

[jc]

From: [EMAIL PROTECTED]
Operating system: FreeBSD 4.3-stable
PHP version:  4.0.6
PHP Bug Type: mcrypt related
Bug description:  mcrypt_generic() leaks memory

Minimal configuration

./configure  --without-mysql --with-apache=../apache_1.3.20 --without-gd 
--without-zlib --without-gdbm
--without-shared-apache --with-mcrypt

libmcrypt versions 2.2.7, 2.4.10, 2.4.11, 2.4.15
php versions 4.0.4pl1, 4.0.5, 4.0.6

This script leaks about 6MB per execution on my system.


encrypt($input);
$x = $CBC->decrypt($block);

if ($x != $input)
print "$x\n";
?>


Modifying PEAR/Crypt/CBC.php to use mcrypt_ecb() instead of
mcrypt_generic() reduces memory leak to less than 1MB
after 1000 executions.





-- 
Edit Bug report at: http://bugs.php.net/?id=11642&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 #11627 Updated: string '0' treated as empty

[brianlmoon]

ID: 11627
Updated by: brianlmoon
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: Unknown/Other Function
Operating system: 
PHP Version: 4.0.5
Assigned To: 
Comments:

Actually, you should get an error on that line.

empty takes a variable, not a value.

Previous Comments:
---

[2001-06-23 14:29:39] [EMAIL PROTECTED]
Yes, this is intentional. Check the manual page for it:

http://www.php.net/empty



---

[2001-06-23 07:54:37] [EMAIL PROTECTED]
the string '0' is not empty but treated as empty

if( empty( '0' ) )
{

}

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=11627&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] Re: Bug #9264 Updated: Using session_encode with user-level session storage functions causes a crash

[Loïc]

Hi sniper!
 
Sorry that you have to reopen the bug but happy to 
see I'm not so
mad ;)
 
BTW as a wrote a few messages before this bug seems 
to be fixed
with the zend snapshots since 2001-06-15, at least 
for the cgi.
 
Thanks again for your attention,
Loïc

Re: [PHP-DEV] Re: Bug #11638 Updated: Compile --with-gd causes error

[Jani Taskinen]

--with-jpeg-dir
--with-png-dir

--Jani


On Sun, 24 Jun 2001, Bill Negrelli wrote:

>Attached is my debug.log, can you offer any insight to the errors?>
>
>thanks.
>
>-=Bill
>
>
>
>On 24 Jun 2001, Bug Database wrote:
>
>> ID: 11638
>> Updated by: sniper
>> Reported By: [EMAIL PROTECTED]
>> Old-Status: Open
>> Status: Bogus
>> Bug Type: *Install and Config
>> Operating system:
>> PHP Version: 4.0.6
>> Assigned To:
>> Comments:
>>
>> I can not reproduce this with GD versions: 1.5 / 1.8.3 / 1.8.4 / 2.0.1. Also, using 
>/usr/lib as path to any
>> configure option is not correct. You must ALWAYS use
>> the install prefix, in this case /usr for --with-jpeg-dir
>>
>> I think you have some conflict with older GD and newer one
>> in your system. Try installing the GD into some other
>> prefix than /usr, e.g. /opt/gd
>>
>> Not bug in PHP.
>>
>> --Jani
>>
>>
>> Previous Comments:
>> ---
>>
>> [2001-06-24 09:09:51] [EMAIL PROTECTED]
>> My configure command is:
>>
>>
>> ./configure --with-gd=/usr --with-jpeg-dir=/usr/lib --enable-track-vars 
>--with-apache=../apache_1.3.20/ --with-mysql
>>
>> make[1]: Entering directory `/usr/src/php-4.0.6/ext'
>> Making all in gd
>> make[2]: Entering directory `/usr/src/php-4.0.6/ext/gd'
>> make[3]: Entering directory `/usr/src/php-4.0.6/ext/gd'
>> gcc  -I. -I/usr/src/php-4.0.6/ext/gd -I/usr/src/php-4.0.6/main -I/usr/src/php-4.0.6 
>-I/usr/src/apache_1.3.20/src/include -I/usr/src/apache_1.3.20/src/os/unix 
>-I/usr/src/php-4.0.6/Zend -I/usr/src/php-4.0.6/ext/mysql/libmysql 
>-I/usr/src/php-4.0.6/ext/xml/expat/xmltok -I/usr/src/php-4.0.6/ext/xml/expat/xmlparse 
>-I/usr/src/php-4.0.6/TSRM  -DSUPPORT_UTF8 -DXML_BYTE_ORDER=12 -g -O2  -c gd.c && 
>touch gd.lo
>> gd.c:95: conflicting types for `gdIOCtx'
>> /usr/include/gd_io.h:18: previous declaration of `gdIOCtx'
>> make[3]: *** [gd.lo] Error 1
>> make[3]: Leaving directory `/usr/src/php-4.0.6/ext/gd'
>> make[2]: *** [all-recursive] Error 1
>> make[2]: Leaving directory `/usr/src/php-4.0.6/ext/gd'
>> make[1]: *** [all-recursive] Error 1
>> make[1]: Leaving directory `/usr/src/php-4.0.6/ext'
>> make: *** [all-recursive] Error 1
>>
>> This is reproducable using GD Libs v1.8.x and 2.0.x
>>
>> PHP 4.0.6 and PHP 4.0.6
>>
>> Thanks.
>>
>> ---
>>
>>
>>
>> ATTENTION! Do NOT reply to this email!
>> To reply, use the web interface found at http://bugs.php.net/?id=11638&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] Sablotron leaks

[Stanislav Malyshev]

Wehn using Sablotron extension, I see the following leaks:

/home/frodo/php4/ext/sablot/sablot.c(1397) :  Freeing 0x083AF0FC (12
bytes), script=test_xsl.php
Last leak repeated 899 times
/home/frodo/php4/ext/sablot/sablot.c(555) :  Freeing 0x083F11F4 (77
bytes), script=test_xsl.php
Last leak repeated 48 times

Anybody know where to fix them? Repeat count looks pretty nasty...
-- 
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: Bug #11638 Updated: Compile --with-gd causes error

[Bill Negrelli]

Attached is my debug.log, can you offer any insight to the errors?>

thanks.

-=Bill



On 24 Jun 2001, Bug Database wrote:

> ID: 11638
> Updated by: sniper
> Reported By: [EMAIL PROTECTED]
> Old-Status: Open
> Status: Bogus
> Bug Type: *Install and Config
> Operating system: 
> PHP Version: 4.0.6
> Assigned To: 
> Comments:
> 
> I can not reproduce this with GD versions: 1.5 / 1.8.3 / 1.8.4 / 2.0.1. Also, using 
>/usr/lib as path to any
> configure option is not correct. You must ALWAYS use
> the install prefix, in this case /usr for --with-jpeg-dir
> 
> I think you have some conflict with older GD and newer one
> in your system. Try installing the GD into some other
> prefix than /usr, e.g. /opt/gd 
> 
> Not bug in PHP.
> 
> --Jani
> 
> 
> Previous Comments:
> ---
> 
> [2001-06-24 09:09:51] [EMAIL PROTECTED]
> My configure command is:
> 
> 
> ./configure --with-gd=/usr --with-jpeg-dir=/usr/lib --enable-track-vars 
>--with-apache=../apache_1.3.20/ --with-mysql
> 
> make[1]: Entering directory `/usr/src/php-4.0.6/ext'
> Making all in gd
> make[2]: Entering directory `/usr/src/php-4.0.6/ext/gd'
> make[3]: Entering directory `/usr/src/php-4.0.6/ext/gd'
> gcc  -I. -I/usr/src/php-4.0.6/ext/gd -I/usr/src/php-4.0.6/main -I/usr/src/php-4.0.6 
>-I/usr/src/apache_1.3.20/src/include -I/usr/src/apache_1.3.20/src/os/unix 
>-I/usr/src/php-4.0.6/Zend -I/usr/src/php-4.0.6/ext/mysql/libmysql 
>-I/usr/src/php-4.0.6/ext/xml/expat/xmltok -I/usr/src/php-4.0.6/ext/xml/expat/xmlparse 
>-I/usr/src/php-4.0.6/TSRM  -DSUPPORT_UTF8 -DXML_BYTE_ORDER=12 -g -O2  -c gd.c && 
>touch gd.lo
> gd.c:95: conflicting types for `gdIOCtx'
> /usr/include/gd_io.h:18: previous declaration of `gdIOCtx'
> make[3]: *** [gd.lo] Error 1
> make[3]: Leaving directory `/usr/src/php-4.0.6/ext/gd'
> make[2]: *** [all-recursive] Error 1
> make[2]: Leaving directory `/usr/src/php-4.0.6/ext/gd'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/usr/src/php-4.0.6/ext'
> make: *** [all-recursive] Error 1
> 
> This is reproducable using GD Libs v1.8.x and 2.0.x
> 
> PHP 4.0.6 and PHP 4.0.6
> 
> Thanks.
> 
> ---
> 
> 
> 
> ATTENTION! Do NOT reply to this email!
> To reply, use the web interface found at http://bugs.php.net/?id=11638&edit=2
> 

-- 


BillyZ.com


CONFIGURE:   './configure' '--with-apache=../apache_1.3.20/' '--with-mysql' 
'--with-gd' '--enable-track-vars' '--enable-debug=no'
CC: gcc
CFLAGS: -g -O2
CPPFLAGS:-DSUPPORT_UTF8
CXX:
CXXFLAGS:   
INCLUDES:-I/usr/src/apache_1.3.20/src/include -I/usr/src/apache_1.3.20/src/os/unix 
 -I$(top_builddir)/Zend -I/usr/src/php-4.0.6/ext/mysql/libmysql
LDFLAGS:
LIBS:   -lgd -lcrypt -lresolv -lm -ldl -lnsl  -lresolv
DLIBS:  
SAPI:   apache
PHP_RPATHS: 
uname -a:   Linux sigma6 2.4.4 #3 SMP Fri May 25 17:07:40 EDT 2001 i686 unknown

gcc -o conftest -g -O2  -DSUPPORT_UTF8  conftest.c -lgd -lcrypt -lresolv -lm -ldl 
-lnsl  -lresolv 1>&5
/usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../libgd.so: undefined reference to 
`uncompress'
/usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../libgd.so: undefined reference to 
`FT_Init_FreeType'
/usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../libgd.so: undefined reference to 
`jpeg_read_scanlines'
/usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../libgd.so: undefined reference to 
`jpeg_simple_progression'
/usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../libgd.so: undefined reference to 
`FT_Load_Glyph'
/usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../libgd.so: undefined reference to 
`FT_Done_Face'
/usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../libgd.so: undefined reference to 
`png_get_rowbytes'
/usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../libgd.so: undefined reference to 
`png_set_strip_16'
/usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../libgd.so: undefined reference to 
`png_create_read_struct'
/usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../libgd.so: undefined reference to 
`FT_Get_Kerning'
/usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../libgd.so: undefined reference to 
`FT_Get_Char_Index'
/usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../libgd.so: undefined reference to 
`png_set_sig_bytes'
/usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../libgd.so: undefined reference to 
`jpeg_set_defaults'
/usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../libgd.so: undefined reference to 
`png_set_read_fn'
/usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../libgd.so: undefined reference to 
`png_set_packing'
/usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../libgd.so: undefined reference to 
`FT_Get_Glyph'
/usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../libgd.so: undefined reference to 
`png_get_io_ptr'
/usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../libgd.so: undefined reference to 
`jpeg_start_decompress'
/usr/lib/gcc-lib/i386-redhat-linux/2.96/../

[PHP-DEV] Bug #11617 Updated: crash when restoring references

[sniper]

ID: 11617
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Bug Type: *Session related
Operating system: 
PHP Version: 4.0 Latest CVS (2001-06-22)
Assigned To: 
Comments:

And the GDB backtrace is where? Please include it.


Previous Comments:
---

[2001-06-24 11:29:39] [EMAIL PROTECTED]
Tried, but php still changed. Maybe it is something with CVS (forgot to commit?), I've 
checked session.c revision and result was:

revision 1.213
date: 2001/06/21 18:46:25;  author: thies;  state: Exp;  lines: +31 -26

I've submitted this bug later.

Zork

---

[2001-06-23 17:34:50] [EMAIL PROTECTED]
Could you please try again? The fix wasn't ok, but now
it's been rewritten and should work.

If it still crashes, try to generate a gdb backtrace of
the crash. And thank you for helping!

--Jani
 

---

[2001-06-22 11:01:25] [EMAIL PROTECTED]
There is still problem in serialize/unserialize mechanism  used to restore session 
variables(after closing #8676 bug which was supoused to correct the problem). Here is 
simplest script I can produce that does apache segfault on my machine:

 frames = array();
}
};

class CError_handler {
var $msg_error;

function CError_handler() {
$this -> msg_error = new CMessage();
}
};

class CConnection_Table {
var $data;

function CConnection_table() {
$this -> data = array();
}

function mconnect($message,&$object,$method) {
$data[0] = &$object;
$data[1] = $method;
$this -> data[$message -> msg_id][] = $data;
}
};

class CMessage {
var $data;
var $msg_id;

function CMessage($data = 0) {
global $__CMSGID_NEXT;
$this -> msg_id = $__CMSGID_NEXT++;
$this -> data = $data;
}
};

function MCONNECT(&$message,&$obj_name,$method_name) {
global $__connection_table;
$__connection_table -> mconnect($message,$obj_name,$method_name);
};

session_start();
session_destroy();
$__connection_table = new CConnection_table;
session_register("__connection_table");

$screen = new Cscreen();
session_register("screen");

$error_handler = new CError_handler($screen);
MCONNECT($error_handler -> msg_error,$screen,"fatal_error");
session_register("error_handler");
echo "done";
exit();



---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=11617&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 #11641 Updated: --enable-gd-native-tt instead of --enable-gd-native-ttf

[sniper]

ID: 11641
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: Compile Problem
Operating system: 
PHP Version: 4.0.6
Assigned To: 
Comments:

Fixed in CVS. Thanks! 

--Jani


Previous Comments:
---

[2001-06-24 11:43:30] [EMAIL PROTECTED]
when you configure php with --enable-gd-native-ttf it doesn't work. In 'configure' it 
checks for --enable-gd-native-tt. Just a minor typo as it seems.

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=11641&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]

Re: [PHP-DEV] About ext/sockets/

[jeroen]

The documentation has just been updated, stating that the sockets-module is
still experimental.
As has any module having an EXPERIMENTAL file in it's directory.

Because of the experimental status, I don't think phpdev should worry too
much about the
incompatibility, it's the user's own reponsibility to use an experimental
module.

But, now it is renamed, I think the experimental status can be lifted? It
makes a
good impression to me how it is currently designed, I don't know whether it
is
pretty stable? Anyway, the documentation should first be updated.

This brings me to another point, since not-so-long-ago there is a
phpdoc/TODO file,
and we would greatly appreciate it that an entry is added whenever there is
a substantial
change to PHP which should be documented. Of course, it'd even better if you
instead
update the docs yourself ;-).
Updating the TODO will increase the likelyhood that the documentation will
be updated
soon. If you don't have Karma to phpdoc, get it, or simply mail
[EMAIL PROTECTED]


Greetz,
Jeroen (phpdoc)



-- 
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 #11641: --enable-gd-native-tt instead of --enable-gd-native-ttf

[erik]

From: [EMAIL PROTECTED]
Operating system: Slackware 7.1
PHP version:  4.0.6
PHP Bug Type: Compile Problem
Bug description:  --enable-gd-native-tt instead of --enable-gd-native-ttf

when you configure php with --enable-gd-native-ttf it doesn't work. In 'configure' it 
checks for --enable-gd-native-tt. Just a minor typo as it seems.


-- 
Edit Bug report at: http://bugs.php.net/?id=11641&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 #10828 Updated: sometimes get_extension_funcs() kills PHP

[sniper]

ID: 10828
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Bug Type: PHP options/info functions
Operating system: 
PHP Version: 4.0.6
Assigned To: 
Comments:

Does it crash? Provide a GDB backtrace then.
(reconfigure/compile PHP first with --enable-debug)

Remember to delete config.cache before configure.
And do 'make clean' after.

--Jani


Previous Comments:
---

[2001-06-24 10:25:36] [EMAIL PROTECTED]
Sorry, but he same in PHP4.0.6


---

[2001-06-10 21:25:40] [EMAIL PROTECTED]
No feedback. Closing.

- James

---

[2001-05-14 08:37:45] [EMAIL PROTECTED]
Your script works for me just fine with PHP 4.0.6-dev.
Please try latest snapshot from http://snaps.php.net/

--Jani




---

[2001-05-12 08:32:35] [EMAIL PROTECTED]
I tried to print out all available PHP functions using 
get_loaded_extensions() and get_extension_funcs():
PHP" . phpversion() . "n");
print("n");
$ext = get_loaded_extensions();
sort($ext);
for($i = 0; $i < count($ext); $i++) {
$name = $ext[$i];
print("$name:nn");
$func = get_extension_funcs($name);
sort($func);
for($j = 0; $j < count($func); $j++) {

print("$func[$j]()n");
}
print("n");
}
print("n");
?>
and this worked well with PHP4.0.3pl1.
However, since PHP4.0.4pl1/5, the Apache (1.3.19) 
subprocess dies:
[Sat May 12 14:26:49 2001] [notice] child pid 746 exit 
signal Segmentation fault (11)
When commenting out the get_extension_funcs() call, all is 
well. Even replacing the argument to a const (eg. 
get_extension_funcs("exif") ) works.
I tried to reproduce the error in a more simple way, but 
failed:

works as expected. Still the script above fails.


---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10828&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]

Re: [PHP-DEV] About ext/sockets/

[Andi Gutmans]

Maybe we should wait with this whole API change until a new sub-version? 
4.1? Or keep the old functionality right now and just add the new 
functions? We can deprecate the old ones in 4.1.

Andi

At 03:03 PM 6/24/2001 +0200, Jani Taskinen wrote:

>Since everybody seems to be using some stupid filters which filters
>all emails which have 'Bug' in the Subject I have to mail this again..
>(Hint: There is X-PHP-Bug: header in those emails that come from bug system)
>
>Anyway, we have a problem. The sockets extension is seriously fucked up
>now. Some functions don't work at all and some work differently than
>before the renaming of the function names. ie. they return FALSE
>on errors now..before they returned -1. Good example: socket_listen()
>
>This is really bad thing and breaks every single script out there
>which uses these functions. It would be acceptable that the function
>names only needed to be changed, but now there has to be really big
>changes in the whole logic the scripts work.
>
>(even our example scripts on manual don't work)
>
>--Jani
>
>
>On 22 Jun 2001 [EMAIL PROTECTED] wrote:
>
> >From: [EMAIL PROTECTED]
> >Operating system: Slackware-current / Kernel 2.4.5
> >PHP version:  4.0 Latest CVS (2001-06-22)
> >PHP Bug Type: Sockets related
> >Bug description:  Socket function examples scripts aren't working with 
> latest CVS
> >
> >After checking the renamed socket functions, i tried to get the sockets
> >example script running. It works fine under 4.0.5, so i renamed the
> >functions to the new ones, und tried to get it running. It started, and i
> >could connect without problems, but instead of being an echo server, i
> >just got disconnectet.
> >When are the new sockets function getting documented with an example 
> script ?
> >thx in advance
>
>
>--
>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 #11617 Updated: crash when restoring references

[zork]

ID: 11617
User Update by: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Open
Bug Type: *Session related
Operating system: Linux 2.2.16 (Cobalt Raq4)
PHP Version: 4.0 Latest CVS (2001-06-22)
Description: crash when restoring references

Tried, but php still changed. Maybe it is something with CVS (forgot to commit?), I've 
checked session.c revision and result was:

revision 1.213
date: 2001/06/21 18:46:25;  author: thies;  state: Exp;  lines: +31 -26

I've submitted this bug later.

Zork

Previous Comments:
---

[2001-06-23 17:34:50] [EMAIL PROTECTED]
Could you please try again? The fix wasn't ok, but now
it's been rewritten and should work.

If it still crashes, try to generate a gdb backtrace of
the crash. And thank you for helping!

--Jani
 

---

[2001-06-22 11:01:25] [EMAIL PROTECTED]
There is still problem in serialize/unserialize mechanism  used to restore session 
variables(after closing #8676 bug which was supoused to correct the problem). Here is 
simplest script I can produce that does apache segfault on my machine:

 frames = array();
}
};

class CError_handler {
var $msg_error;

function CError_handler() {
$this -> msg_error = new CMessage();
}
};

class CConnection_Table {
var $data;

function CConnection_table() {
$this -> data = array();
}

function mconnect($message,&$object,$method) {
$data[0] = &$object;
$data[1] = $method;
$this -> data[$message -> msg_id][] = $data;
}
};

class CMessage {
var $data;
var $msg_id;

function CMessage($data = 0) {
global $__CMSGID_NEXT;
$this -> msg_id = $__CMSGID_NEXT++;
$this -> data = $data;
}
};

function MCONNECT(&$message,&$obj_name,$method_name) {
global $__connection_table;
$__connection_table -> mconnect($message,$obj_name,$method_name);
};

session_start();
session_destroy();
$__connection_table = new CConnection_table;
session_register("__connection_table");

$screen = new Cscreen();
session_register("screen");

$error_handler = new CError_handler($screen);
MCONNECT($error_handler -> msg_error,$screen,"fatal_error");
session_register("error_handler");
echo "done";
exit();



---


Full Bug description available at: http://bugs.php.net/?id=11617


-- 
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 #11640: realpath(): wrong results with $PHP_SELF

[c . steinmann]

From: [EMAIL PROTECTED]
Operating system: WIN NT
PHP version:  4.0.6
PHP Bug Type: Filesystem function related
Bug description:  realpath(): wrong results with $PHP_SELF

Hi 

realpath($PHP_SELF);

doesn't give the same result as 

realpath('index.php');

While the result of the second example is correct, the first one outputs only part of 
the value, in my case:

Correct: d:\inetpub\wwwroot\blue\index.php
Result:  d:\blue\index.php

wwwroot is DOCUMENT_ROOT in my case. 
I use NT4/IIS with PHP as ISAPI (not in safe mode).

Christoph


-- 
Edit Bug report at: http://bugs.php.net/?id=11640&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 #10828 Updated: sometimes get_extension_funcs() kills PHP

[jo]

ID: 10828
User Update by: [EMAIL PROTECTED]
Old-Status: Closed
Status: Open
Bug Type: PHP options/info functions
Operating system: Linux 2.4.5
PHP Version: 4.0.6
Description: sometimes get_extension_funcs() kills PHP

Sorry, but he same in PHP4.0.6


Previous Comments:
---

[2001-06-10 21:25:40] [EMAIL PROTECTED]
No feedback. Closing.

- James

---

[2001-05-14 08:37:45] [EMAIL PROTECTED]
Your script works for me just fine with PHP 4.0.6-dev.
Please try latest snapshot from http://snaps.php.net/

--Jani




---

[2001-05-12 08:32:35] [EMAIL PROTECTED]
I tried to print out all available PHP functions using 
get_loaded_extensions() and get_extension_funcs():
PHP" . phpversion() . "n");
print("n");
$ext = get_loaded_extensions();
sort($ext);
for($i = 0; $i < count($ext); $i++) {
$name = $ext[$i];
print("$name:nn");
$func = get_extension_funcs($name);
sort($func);
for($j = 0; $j < count($func); $j++) {

print("$func[$j]()n");
}
print("n");
}
print("n");
?>
and this worked well with PHP4.0.3pl1.
However, since PHP4.0.4pl1/5, the Apache (1.3.19) 
subprocess dies:
[Sat May 12 14:26:49 2001] [notice] child pid 746 exit 
signal Segmentation fault (11)
When commenting out the get_extension_funcs() call, all is 
well. Even replacing the argument to a const (eg. 
get_extension_funcs("exif") ) works.
I tried to reproduce the error in a more simple way, but 
failed:

works as expected. Still the script above fails.


---


Full Bug description available at: http://bugs.php.net/?id=10828


-- 
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 #11593 Updated: varchar(8000) field in MSSQL returns only 4096 chars

[cm]

ID: 11593
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: MSSQL related
Operating system: NT4.0
PHP Version: 4.0.6
Description: varchar(8000) field in MSSQL returns only 4096 chars

still the same on the new version 4.0.6. mssql_fetch_array() delivers only the first 
4k. please help.

Previous Comments:
---

[2001-06-20 17:22:32] [EMAIL PROTECTED]
i have a table with varchar(8000) fields. tried to get the content. php delivers only 
the first 4k. odbc delivers the full range... i've added in the php.ini the setings 
for mssql.textlimit to 8192 and for mssql.textsize to 8192, too

phpinfo() shows me my ini-settings but the content is stille 4k. please help asap. 
many thanks and best regards christian marnitz

---


Full Bug description available at: http://bugs.php.net/?id=11593


-- 
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 #11639 Updated: Errores de operación con enteros negativos

[sniper]

ID: 11639
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: *Math Functions
Operating system: 
PHP Version: 4.0.5
Assigned To: 
Comments:

RTFM:

"These math functions will only handle values within the range of the long and double 
types on your computer. 
If you need to handle bigger numbers, take a look at the arbitrary precision math 
functions."

http://www.php.net/bc



Previous Comments:
---

[2001-06-24 09:16:04] [EMAIL PROTECTED]
";
echo "Resultado de PHP...: ",$f,"";

echo "Resultado correcto de a+c= -2147483660";
echo "Resultado de PHP...: ",$r,"";

echo "Resultado correcto de d+e= -2147483648";
echo "Resultado de PHP...: ",$m,"";

echo "Resultado correcto de s+b= -2147483687";
echo "Resultado de PHP...: ",$w,"";

?>




---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=11639&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 #11638 Updated: Compile --with-gd causes error

[sniper]

ID: 11638
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Bogus
Bug Type: *Install and Config
Operating system: 
PHP Version: 4.0.6
Assigned To: 
Comments:

I can not reproduce this with GD versions: 1.5 / 1.8.3 / 1.8.4 / 2.0.1. Also, using 
/usr/lib as path to any
configure option is not correct. You must ALWAYS use
the install prefix, in this case /usr for --with-jpeg-dir

I think you have some conflict with older GD and newer one
in your system. Try installing the GD into some other
prefix than /usr, e.g. /opt/gd 

Not bug in PHP.

--Jani


Previous Comments:
---

[2001-06-24 09:09:51] [EMAIL PROTECTED]
My configure command is:


./configure --with-gd=/usr --with-jpeg-dir=/usr/lib --enable-track-vars 
--with-apache=../apache_1.3.20/ --with-mysql

make[1]: Entering directory `/usr/src/php-4.0.6/ext'
Making all in gd
make[2]: Entering directory `/usr/src/php-4.0.6/ext/gd'
make[3]: Entering directory `/usr/src/php-4.0.6/ext/gd'
gcc  -I. -I/usr/src/php-4.0.6/ext/gd -I/usr/src/php-4.0.6/main -I/usr/src/php-4.0.6 
-I/usr/src/apache_1.3.20/src/include -I/usr/src/apache_1.3.20/src/os/unix 
-I/usr/src/php-4.0.6/Zend -I/usr/src/php-4.0.6/ext/mysql/libmysql 
-I/usr/src/php-4.0.6/ext/xml/expat/xmltok -I/usr/src/php-4.0.6/ext/xml/expat/xmlparse 
-I/usr/src/php-4.0.6/TSRM  -DSUPPORT_UTF8 -DXML_BYTE_ORDER=12 -g -O2  -c gd.c && touch 
gd.lo
gd.c:95: conflicting types for `gdIOCtx'
/usr/include/gd_io.h:18: previous declaration of `gdIOCtx'
make[3]: *** [gd.lo] Error 1
make[3]: Leaving directory `/usr/src/php-4.0.6/ext/gd'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/usr/src/php-4.0.6/ext/gd'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/src/php-4.0.6/ext'
make: *** [all-recursive] Error 1

This is reproducable using GD Libs v1.8.x and 2.0.x

PHP 4.0.6 and PHP 4.0.6

Thanks.

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=11638&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 #11639: Errores de operación con enteros negativos

[rinconastur]

From: [EMAIL PROTECTED]
Operating system: Windows98
PHP version:  4.0.5
PHP Bug Type: *Math Functions
Bug description:  Errores de operación con enteros negativos

";
echo "Resultado de PHP...: ",$f,"";

echo "Resultado correcto de a+c= -2147483660";
echo "Resultado de PHP...: ",$r,"";

echo "Resultado correcto de d+e= -2147483648";
echo "Resultado de PHP...: ",$m,"";

echo "Resultado correcto de s+b= -2147483687";
echo "Resultado de PHP...: ",$w,"";

?>





-- 
Edit Bug report at: http://bugs.php.net/?id=11639&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 #11638: Compile --with-gd causes error

[billyz]

From: [EMAIL PROTECTED]
Operating system: RedHat Linux 7.0 kernel 2.4.2
PHP version:  4.0.6
PHP Bug Type: *Install and Config
Bug description:  Compile --with-gd causes error

My configure command is:


./configure --with-gd=/usr --with-jpeg-dir=/usr/lib --enable-track-vars 
--with-apache=../apache_1.3.20/ --with-mysql

make[1]: Entering directory `/usr/src/php-4.0.6/ext'
Making all in gd
make[2]: Entering directory `/usr/src/php-4.0.6/ext/gd'
make[3]: Entering directory `/usr/src/php-4.0.6/ext/gd'
gcc  -I. -I/usr/src/php-4.0.6/ext/gd -I/usr/src/php-4.0.6/main -I/usr/src/php-4.0.6 
-I/usr/src/apache_1.3.20/src/include -I/usr/src/apache_1.3.20/src/os/unix 
-I/usr/src/php-4.0.6/Zend -I/usr/src/php-4.0.6/ext/mysql/libmysql 
-I/usr/src/php-4.0.6/ext/xml/expat/xmltok -I/usr/src/php-4.0.6/ext/xml/expat/xmlparse 
-I/usr/src/php-4.0.6/TSRM  -DSUPPORT_UTF8 -DXML_BYTE_ORDER=12 -g -O2  -c gd.c && touch 
gd.lo
gd.c:95: conflicting types for `gdIOCtx'
/usr/include/gd_io.h:18: previous declaration of `gdIOCtx'
make[3]: *** [gd.lo] Error 1
make[3]: Leaving directory `/usr/src/php-4.0.6/ext/gd'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/usr/src/php-4.0.6/ext/gd'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/src/php-4.0.6/ext'
make: *** [all-recursive] Error 1

This is reproducable using GD Libs v1.8.x and 2.0.x

PHP 4.0.6 and PHP 4.0.6

Thanks.


-- 
Edit Bug report at: http://bugs.php.net/?id=11638&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] About ext/sockets/

[Jani Taskinen]

Since everybody seems to be using some stupid filters which filters
all emails which have 'Bug' in the Subject I have to mail this again..
(Hint: There is X-PHP-Bug: header in those emails that come from bug system)

Anyway, we have a problem. The sockets extension is seriously fucked up
now. Some functions don't work at all and some work differently than
before the renaming of the function names. ie. they return FALSE
on errors now..before they returned -1. Good example: socket_listen()

This is really bad thing and breaks every single script out there
which uses these functions. It would be acceptable that the function
names only needed to be changed, but now there has to be really big
changes in the whole logic the scripts work.

(even our example scripts on manual don't work)

--Jani


On 22 Jun 2001 [EMAIL PROTECTED] wrote:

>From: [EMAIL PROTECTED]
>Operating system: Slackware-current / Kernel 2.4.5
>PHP version:  4.0 Latest CVS (2001-06-22)
>PHP Bug Type: Sockets related
>Bug description:  Socket function examples scripts aren't working with latest CVS
>
>After checking the renamed socket functions, i tried to get the sockets
>example script running. It works fine under 4.0.5, so i renamed the
>functions to the new ones, und tried to get it running. It started, and i
>could connect without problems, but instead of being an echo server, i
>just got disconnectet.
>When are the new sockets function getting documented with an example script ?
>thx in advance


-- 
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 #11637 Updated: GD compilation failure with GD1.5

[sniper]

ID: 11637
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Bogus
Bug Type: GD related
Operating system: 
PHP Version: 4.0.6
Assigned To: 
Comments:

You must have some other libgd.a|so which is used
since in my libgd-1.5 there is no gdImageGifCtx() function
in it.

--Jani


Previous Comments:
---

[2001-06-24 02:07:24] [EMAIL PROTECTED]
This is related to bug 10593.  4.0.6 still failes to compile with GD 1.5.  
gdImageGifCtx is indeed in the GD lib, that's why HAVE_GD_GIF_CTX is set.  But 
gdImageGifCtx prototype is not available in GD header files, so the compilation fails. 
 I have changed line 1401 to #ifdef HAVE_GD_GIF_CTX_NEVER_WILL_HAPPEN just to get the 
compilation going.

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=11637&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 #9264 Updated: Using session_encode with user-level session storage functions causes a crash

[sniper]

ID: 9264
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Closed
Status: Analyzed
Bug Type: *Session related
Operating system: 
PHP Version: 4.0 Latest CVS (14/02/2001)
Assigned To: 
Comments:

Reopened. I can reproduce this with PHP 4.0.6:

register_globals=On  ; No crash
register_globasl=Off ; Kaboom!



Previous Comments:
---

[2001-06-24 05:21:55] [EMAIL PROTECTED]
Hi !

Sorry to bother you with this bug report you closed yesterday but I think the bug does 
exist and it's not related to my config because I can reproduce it with all php 
releases > 4.01 except with the latest snapshots from Zend.

I've done some deep testings this night to understand what could be the reason for the 
crash and I've noticed that one must have set the 'register_globals' directive to off 
to face it (wathever is the way php is loaded by Apache and whatever are the 
extensions loaded).

Please ignore this post if you don't have enough time to test bugs reports again and 
again: I can wait the next php4.07 package.

Have a nice and shinny week-end,
Loïc Chapeaux

---

[2001-06-23 17:22:00] [EMAIL PROTECTED]
Can't reproduce this with either PHP 4.0.5 or PHP 4.0.7-dev on Win32.


---

[2001-06-23 05:06:59] [EMAIL PROTECTED]
Hi All!

I've just done some testings with the new php4.06 release and the crash is still here 
with:
- php loaded as a cgi or as an Apache module,
- php.ini = the optimized one (without any extension).

Regards,
Loïc  

---

[2001-06-15 13:33:17] [EMAIL PROTECTED]
Hi sniper and all!

Well, it's not easy to send you an accurate reply because zend snapshots for win32 
does not contain the Apache module.

BTW, Ive done some testings:
- with php4.07-dev from php4win.de the script still crashes Apache with php loaded as 
a gci or as an Apache module;
- with the latest snapshot from zend.com (cgi only), it runs :)

If someone can build the Apache module (I can't do it, sorry :() I may do some more 
tests.

Thanks for your attention,
Loïc

---

[2001-06-14 23:21:56] [EMAIL PROTECTED]
Does this happen with latest CVS snapshot build from
http://www.zend.com/snapshots/ ??



---

The remainder of the comments for this report are too long.  To view the rest of the 
comments, please view the bug report online.


ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9264&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]

Re: [PHP-DEV] Scripting Shootout - PHP ranked 24/29

[Stanislav Malyshev]

JL>> http://www.bagley.org/~doug/shootout/lang/php/
JL>>
JL>> The above site has several benchmarks of 29 programming
JL>> languages, including PHP, Perl and Pike.

I don't really get how this guy came to the claim that PHP has no object
instantiation, method calls, regular expressions or unable to do
statistical calculations. Looks like Yet Another Stupid Benchmark (TM).
Doh.

-- 
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 #11631 Updated: php_interbase.dll problem

[dido]

ID: 11631
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: InterBase related
Operating system: Windows
PHP Version: 4.0.6
Description: php_interbase.dllproblem

Hi there,
I found something strange about the php_interbase.dll included in versions 4.0.6 and
4.0.5. Both dlls in the different versions have the same size, but they return 
diffrent results
from a sql query that uses agregate SUM().
All I do is to select from the table, SUM the results and display them out. When I use 
the
dll included in 4.0.5 the results are acurate. When I use the dll included in 4.0.6 
with
php 4.0.6 instead of exact numbers like 25.0 , I receive 25.2  and this is in all my 
results
( + 0.2 ).



Previous Comments:
---

[2001-06-23 14:39:29] [EMAIL PROTECTED]
Hi there,
I found something strange about the php_interbase.dll included in versions 4.0.6 and 
4.0.5. Both dlls in the different versions have the same size, but they return 
diffrent results from a sql query that uses agregate SUM().
All I do is to select from the table, SUM the results and display them out. When I use 
the dll included in 4.0.5 the results are acurate. When I use the dll included in 
4.0.6 with php 4.0.6 instead of exact numbers like 25.0 , I receive 25.2  and this is 
in all my results ( + 0.2 ).


---


Full Bug description available at: http://bugs.php.net/?id=11631


-- 
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 #9264 Updated: Using session_encode with user-level session storage functions causes a crash

[lolo]

ID: 9264
User Update by: [EMAIL PROTECTED]
Status: Closed
Bug Type: *Session related
Operating system: win98 SE
PHP Version: 4.0 Latest CVS (14/02/2001)
Description: Using session_encode with user-level session storage functions causes a 
crash

Hi !

Sorry to bother you with this bug report you closed yesterday but I think the bug does 
exist and it's not related to my config because I can reproduce it with all php 
releases > 4.01 except with the latest snapshots from Zend.

I've done some deep testings this night to understand what could be the reason for the 
crash and I've noticed that one must have set the 'register_globals' directive to off 
to face it (wathever is the way php is loaded by Apache and whatever are the 
extensions loaded).

Please ignore this post if you don't have enough time to test bugs reports again and 
again: I can wait the next php4.07 package.

Have a nice and shinny week-end,
Loïc Chapeaux

Previous Comments:
---

[2001-06-23 17:22:00] [EMAIL PROTECTED]
Can't reproduce this with either PHP 4.0.5 or PHP 4.0.7-dev on Win32.


---

[2001-06-23 05:06:59] [EMAIL PROTECTED]
Hi All!

I've just done some testings with the new php4.06 release and the crash is still here 
with:
- php loaded as a cgi or as an Apache module,
- php.ini = the optimized one (without any extension).

Regards,
Loïc  

---

[2001-06-15 13:33:17] [EMAIL PROTECTED]
Hi sniper and all!

Well, it's not easy to send you an accurate reply because zend snapshots for win32 
does not contain the Apache module.

BTW, Ive done some testings:
- with php4.07-dev from php4win.de the script still crashes Apache with php loaded as 
a gci or as an Apache module;
- with the latest snapshot from zend.com (cgi only), it runs :)

If someone can build the Apache module (I can't do it, sorry :() I may do some more 
tests.

Thanks for your attention,
Loïc

---

[2001-06-14 23:21:56] [EMAIL PROTECTED]
Does this happen with latest CVS snapshot build from
http://www.zend.com/snapshots/ ??



---

[2001-03-17 12:08:15] [EMAIL PROTECTED]
Hi!

I've done a test with the new php4.0.5-RC1 from php4win.de and the crash still occurs.

Regards,
Loïc

---

The remainder of the comments for this report are too long.  To view the rest of the 
comments, please view the bug report online.

Full Bug description available at: http://bugs.php.net/?id=9264


-- 
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] multiple compilations of SAPI

[Anil Madhavapeddy]

Stig made a brave attempt at allowing the compilation of multiple SAPI
modules simulataneously a while back, but I think this never made it
through to php-4.0.[5|6].

Is there any chance this could get looked at before 4.0.7?  It would
make it so easy to install the CGI binary for PEAR as well as the APXS
module.

Cheers,
Anil


-- 
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]