Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/snmp CREDITS php_snmp.hsnmp.c

[Harrie Hazewinkel]

--On Wednesday, November 13, 2002 2:33 AM +0200 Jani Taskinen 
<[EMAIL PROTECTED]> wrote:


Maybe it would be good idea to do something like
LDAP extension does? ie. have something similar to ldap_set_option()
to set the protocol version to be used? And have same
functions and thus not pollute the function namespace anymore?


This is an option, but then you put a bigger burden on the script
developer. It is very likely possible that SNMPv1 and SNMPv3 calls
are done in various orders in a script. Mainly because not all devices
support SNMPv3 yet.
So from not polluting the C-code portion and the function names used
you go and pollute the scripts. IMHO, that is not a good idea either
and that for just a version number. We as PHP developers of the C-part
should not forget we make this for others and we better make it as
easy as possible for them. Not for us or that things just look better.

An idea could be that a the complete 'session' is create and that is
then given to the data retrieval functions like snmpget.
A create_session would provide all parameters and the combined
arguments go into the data retrieval part by menas of the C-struct
'struct snmp_session' that is used.



iirc, the snmp command line tools have an option to select
which protocol version to use?


That is correct. However, I tried to avoid that. The
parameters betwen SNMPv1 and SNMPv3 are completely different.



Harrie

Internet Management Consulting
mailto: [EMAIL PROTECTED]   http://www.lisanza.net/

Author of MOD-SNMP, enabling SNMP management the Apache HTTP server 

--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] karma++

[Philip Olson]

Hello-

I request karma for phpweb and php4/NEWS  

I will help close bugs related to these 
categories and help make improvements.

Regards,
Philip Olson

user: philip


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] mbstring and 4.3.0

[Derick Rethans]

On Wed, 13 Nov 2002, Moriyoshi Koizumi wrote:

> --snip
> > uhm, I don't think it works stable enough.
> 
> I think the decision making went right, and I've got no more objection to 
> that point. but I wonder how this could be certified as a stable module 
> that is not widely used by the core developers?

For me it was the wide stream of bugreports coming in; can't speak for 
the others though.

Derick

-- 

---
 Derick Rethans   http://derickrethans.nl/ 
 JDI Media Solutions
--[ if you hold a unix shell to your ear, do you hear the c? ]-


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] mbstring and 4.3.0

[Moriyoshi Koizumi]

--snip
> uhm, I don't think it works stable enough.

I think the decision making went right, and I've got no more objection to 
that point. but I wonder how this could be certified as a stable module 
that is not widely used by the core developers?

Moriyoshi

> 
> 
> Derick
> 
> -- 
> 
> ---
>  Derick Rethans   http://derickrethans.nl/ 
>  JDI Media Solutions
> --[ if you hold a unix shell to your ear, do you hear the c? ]-
> 
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
> 


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] mbstring and 4.3.0

[Derick Rethans]

On Wed, 13 Nov 2002, Yasuo Ohgaki wrote:

> Jani Taskinen wrote:
> >
> >Oh, I forgot: How many bug reports have we got so
> >far for that fuckup with 4.2.3 ??? I _REALLY_ don't want
> >to see another wave of those for 4.3.0..
> 
> Do you mean array input handling bug?
> It's not mbstring developers' fault.

It doesn't really matter who's fault it was, it's a fact that the 
mbstring module caused this fuckup.

Derick

-- 

---
 Derick Rethans   http://derickrethans.nl/ 
 JDI Media Solutions
--[ if you hold a unix shell to your ear, do you hear the c? ]-


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] mbstring and 4.3.0

[Derick Rethans]

On Wed, 13 Nov 2002, Marcus Börger wrote:

> At 04:11 13.11.2002, Jani Taskinen wrote:
> 
> > Since when have we started to use users as guinea-pigs
> > for testing EXPERIMENTAL extensions without them even
> > really knowing about it?!!
> 
> mbstring is not EXPERIMENTAL and i said let them try it. That
> does not mean test it. We think it works .

uhm, I don't think it works stable enough.


Derick

-- 

---
 Derick Rethans   http://derickrethans.nl/ 
 JDI Media Solutions
--[ if you hold a unix shell to your ear, do you hear the c? ]-


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] mbstring and 4.3.0

[Ilia A.]

On November 13, 2002 12:28 am, Moriyoshi Koizumi wrote:
> Hmm, there might be no much need to fix this bug as it is not
> enabled by default... If the script still sefaults with my patch, I can no
> longer determine theplace at which it goes wrong just with your backtrace
> precisely, as it is apparently a double-free bug.

I'll look into the problem in more detail tommorow.

Ilia

> Moriyoshi
>
> "Ilia A." <[EMAIL PROTECTED]> wrote:
> > I've just tried the latest CVS, it still crashes, the backtrace is same
> > as before.
> >
> > Ilia
> >
> > On November 12, 2002 05:21 pm, Moriyoshi Koizumi wrote:
> > > Oops, why didn't I notice such a trivial thing before asking a
> > > braindead question... Anyway I bet the problem should be gone by my
> > > patch that was just commited.
> > >
> > > Moriyoshi
> > >
> > > "Ilia A." <[EMAIL PROTECTED]> wrote:
> > > > On November 12, 2002 04:58 pm, Moriyoshi Koizumi wrote:
> > > > > Hi,
> > > > >
> > > > > Thanks for the report.
> > > > > Although I found a bug in the overloading code, I wonder why the
> > > > > mail() function entry was not found on RINIT. Any insights?
> > > >
> > > > It seems the mail() function is not avaliable on that system because
> > > > sendmail was not found on the system. The function mail() on unix
> > > > systems appears to be dependant on sendmail avaliablity or atleast
> > > > something that would cause the HAVE_SENDMAIL flag to be set.
> > > >
> > > > Ilia
> > > >
> > > > > Moriyoshi
> > > > >
> > > > > "Ilia A." <[EMAIL PROTECTED]> wrote:
> > > > > > On November 7, 2002 10:04 am, Andrei Zmievski wrote:
> > > > > > > At the PHP Conference in Germany several of us have discussed
> > > > > > > the current state of mbstring and there was a proposal to not
> > > > > > > have it enabled by default for 4.3.0 release. It seems that the
> > > > > > > extension attempts to do "magic" stuff by overloading functions
> > > > > > > in the executor globals and, as Thies said, that could be
> > > > > > > dangerous. Also, doesn't it affect run-tests.php script
> > > > > > > currently?
> > > > > >
> > > > > > On the note of overloading done by mbstring, it appears this
> > > > > > behavior is not entirely stable. On at least one test system (Sun
> > > > > > OS 5.9) it causes crashes and overruns by using the test script
> > > > > > in the test suite. Ex:
> > > > > > sapi/cli/php -d "mbstring.func_overload=1" -r ''
> > > > > > Unknown(0) : Fatal error - (null)()
> > > > > > [http://www.php.net/ref.mbstring]: mbstring couldn't find
> > > > > > function mail.
> > > > > > Could not startup.
> > > > > > [Tue Nov 12 21:01:33 2002]  Script:  '-'
> > > > > > ---
> > > > > > php4/Zend/zend_execute.h(44) : Block 0x001FB640 status:
> > > > > > Beginning:  Overrun (magic=0x001FE7F8, expected=0x7312F8DC)
> > > > > >   End:  Unknown
> > > > > > ---
> > > > > >
> > > > > > The test script itself (ext/mbstring/tests/overload.phpt) causes
> > > > > > a segmentation fault. Here is a back trace:
> > > > > > #0  0x001528f8 in shutdown_memory_manager (silent=1,
> > > > > > clean_cache=1) at php4/Zend/zend_alloc.c:461
> > > > > > #1  0x0011d944 in php_module_shutdown () at php4/main/main.c:1219
> > > > > > #2  0x0018d8d0 in main (argc=39, argv=0xffbffa74) at
> > > > > > php4/sapi/cli/php_cli.c:761
> > > > > >
> > > > > > Ilia
> > > > > >
> > > > > > --
> > > > > > PHP Development Mailing List 
> > > > > > To unsubscribe, visit: http://www.php.net/unsub.php
> > > >
> > > > --
> > > > PHP Development Mailing List 
> > > > To unsubscribe, visit: http://www.php.net/unsub.php


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] mbstring and 4.3.0

[Moriyoshi Koizumi]

Hmm, there might be no much need to fix this bug as it is not
enabled by default... If the script still sefaults with my patch, I can no 
longer determine theplace at which it goes wrong just with your backtrace precisely, 
as it is apparently a double-free bug.

Moriyoshi

"Ilia A." <[EMAIL PROTECTED]> wrote:

> I've just tried the latest CVS, it still crashes, the backtrace is same as 
> before.
> 
> Ilia
> 
> On November 12, 2002 05:21 pm, Moriyoshi Koizumi wrote:
> > Oops, why didn't I notice such a trivial thing before asking a braindead
> > question... Anyway I bet the problem should be gone by my patch that was
> > just commited.
> >
> > Moriyoshi
> >
> > "Ilia A." <[EMAIL PROTECTED]> wrote:
> > > On November 12, 2002 04:58 pm, Moriyoshi Koizumi wrote:
> > > > Hi,
> > > >
> > > > Thanks for the report.
> > > > Although I found a bug in the overloading code, I wonder why the mail()
> > > > function entry was not found on RINIT. Any insights?
> > >
> > > It seems the mail() function is not avaliable on that system because
> > > sendmail was not found on the system. The function mail() on unix systems
> > > appears to be dependant on sendmail avaliablity or atleast something that
> > > would cause the HAVE_SENDMAIL flag to be set.
> > >
> > > Ilia
> > >
> > > > Moriyoshi
> > > >
> > > > "Ilia A." <[EMAIL PROTECTED]> wrote:
> > > > > On November 7, 2002 10:04 am, Andrei Zmievski wrote:
> > > > > > At the PHP Conference in Germany several of us have discussed the
> > > > > > current state of mbstring and there was a proposal to not have it
> > > > > > enabled by default for 4.3.0 release. It seems that the extension
> > > > > > attempts to do "magic" stuff by overloading functions in the
> > > > > > executor globals and, as Thies said, that could be dangerous. Also,
> > > > > > doesn't it affect run-tests.php script currently?
> > > > >
> > > > > On the note of overloading done by mbstring, it appears this behavior
> > > > > is not entirely stable. On at least one test system (Sun OS 5.9) it
> > > > > causes crashes and overruns by using the test script in the test
> > > > > suite. Ex:
> > > > > sapi/cli/php -d "mbstring.func_overload=1" -r ''
> > > > > Unknown(0) : Fatal error - (null)()
> > > > > [http://www.php.net/ref.mbstring]: mbstring couldn't find function
> > > > > mail.
> > > > > Could not startup.
> > > > > [Tue Nov 12 21:01:33 2002]  Script:  '-'
> > > > > ---
> > > > > php4/Zend/zend_execute.h(44) : Block 0x001FB640 status:
> > > > > Beginning:  Overrun (magic=0x001FE7F8, expected=0x7312F8DC)
> > > > >   End:  Unknown
> > > > > ---
> > > > >
> > > > > The test script itself (ext/mbstring/tests/overload.phpt) causes a
> > > > > segmentation fault. Here is a back trace:
> > > > > #0  0x001528f8 in shutdown_memory_manager (silent=1, clean_cache=1)
> > > > > at php4/Zend/zend_alloc.c:461
> > > > > #1  0x0011d944 in php_module_shutdown () at php4/main/main.c:1219
> > > > > #2  0x0018d8d0 in main (argc=39, argv=0xffbffa74) at
> > > > > php4/sapi/cli/php_cli.c:761
> > > > >
> > > > > Ilia
> > > > >
> > > > > --
> > > > > PHP Development Mailing List 
> > > > > To unsubscribe, visit: http://www.php.net/unsub.php
> > >
> > > --
> > > PHP Development Mailing List 
> > > To unsubscribe, visit: http://www.php.net/unsub.php
> 


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] prototypes for getters and setters.

[John Coggeshall]

I understand what your saying, however I guess I see the tradeoff of
creating a new reserved word to a (IMHO of course) kinda messy new
syntax a good one. 

Besides, having an absolute standard for get/set would be benefital to
all developers.. Knowing that setting $foo is always setfoo() (or
set_foo(), makes no difference) would be nice. 

As for assuming the user knows how the syntax works, that'd be the same
thing with any new syntax at all... 

John


|-Original Message-
|From: Alan Knowles [mailto:alan@;akbkhome.com] 
|Sent: Wednesday, November 13, 2002 12:10 AM
|To: John Coggeshall
|Cc: [EMAIL PROTECTED]
|Subject: Re: [PHP-DEV] prototypes for getters and setters.
|
|
|the trouble is that you will make pubvar a reserved word, and 
|you force 
|the user to use a fixed standard for set/get -- eg. some users 
|may like 
|get_orange, others may want getOrange
|It also makes the assumtion that the user knows how the syntax 
|works.. - 
|eg. searching the file for  getOrange would return nothing...
|
|Regards
|Alan
|
|John Coggeshall wrote:
|
|>What about something like this...
|>
|>Class foo {
|>  
|>  var $myfoo; // "Private" variable
|>  pubvar $myfoo2; // "Public" variable
|>
|>
|>}
|>
|>Class bar extends foo {
|>
|>  pubvar $mystuff;
|>
|>}
|>
|>$a = new foo();
|>$a->setmyfoo2(5);
|>echo $a->getmyfoo2();
|>
|>$b = new bar();
|>$b->setmyfoo2(10);
|>$b->setmystuff(20);
|>
|>The point here is that pubvar automatically creates get* and 
|set*.. As 
|>far as overloading, etc is concerned, there would be no need to worry 
|>about it -- the point of these functions is not to overload 
|them (they 
|>should simply be used to get and set member variables)...
|>
|>John
|>
|>|-Original Message-
|>|From: Shane Caraveo [mailto:shane@;caraveo.com]
|>|Sent: Tuesday, November 12, 2002 10:04 PM
|>|To: Alan Knowles
|>|Cc: [EMAIL PROTECTED]
|>|Subject: Re: [PHP-DEV] prototypes for getters and setters.
|>|
|>|
|>|Alan Knowles wrote:
|>|
|>|> Shane Caraveo wrote:
|>|>
|>|> >>
|>|> >>
|>|> >> Anyway before I get carried away and actually test this :) -
|>|> anybody got
|>|> >> any thoughts.
|>|> >>
|>|> >> Regards
|>|> >> Alan
|>|> >
|>|> >
|>|> >
|>|> >
|>|> > What's wrong with how overload does this?
|>|>
|>|>
|>|> it has a slight downside in clarity of code - eg. where is that
|>|> method..
|>|>
|>|But it (overload) also does not introduce new syntax, requires no
|>|changes to the engine, is genericly overrideable in extensions, etc. 
|>|etc. etc.
|>|
|>|Shane
|>|
|>|
|>|--
|>|PHP Development Mailing List 
|>|To unsubscribe, visit: http://www.php.net/unsub.php
|>|
|>|
|>
|>
|>  
|>
|
|
|


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] prototypes for getters and setters.

[Alan Knowles]

the trouble is that you will make pubvar a reserved word, and you force 
the user to use a fixed standard for set/get -- eg. some users may like 
get_orange, others may want getOrange
It also makes the assumtion that the user knows how the syntax works.. - 
eg. searching the file for  getOrange would return nothing...

Regards
Alan

John Coggeshall wrote:

What about something like this...

Class foo {
	
	var $myfoo; 	// "Private" variable
	pubvar $myfoo2;	// "Public" variable


}

Class bar extends foo {

	pubvar $mystuff;

}

$a = new foo();
$a->setmyfoo2(5);
echo $a->getmyfoo2();

$b = new bar();
$b->setmyfoo2(10);
$b->setmystuff(20);

The point here is that pubvar automatically creates get* and set*.. As
far as overloading, etc is concerned, there would be no need to worry
about it -- the point of these functions is not to overload them (they
should simply be used to get and set member variables)... 

John

|-Original Message-
|From: Shane Caraveo [mailto:shane@;caraveo.com] 
|Sent: Tuesday, November 12, 2002 10:04 PM
|To: Alan Knowles
|Cc: [EMAIL PROTECTED]
|Subject: Re: [PHP-DEV] prototypes for getters and setters.
|
|
|Alan Knowles wrote:
|
|> Shane Caraveo wrote:
|>
|> >>
|> >>
|> >> Anyway before I get carried away and actually test this :) -
|> anybody got
|> >> any thoughts.
|> >>
|> >> Regards
|> >> Alan
|> >
|> >
|> >
|> >
|> > What's wrong with how overload does this?
|>
|>
|> it has a slight downside in clarity of code - eg. where is that 
|> method..
|>
|But it (overload) also does not introduce new syntax, requires no 
|changes to the engine, is genericly overrideable in extensions, etc. 
|etc. etc.
|
|Shane
|
|
|-- 
|PHP Development Mailing List 
|To unsubscribe, visit: http://www.php.net/unsub.php
|
|


 




--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] prototypes for getters and setters.

[John Coggeshall]

What about something like this...

Class foo {

var $myfoo; // "Private" variable
pubvar $myfoo2; // "Public" variable


}

Class bar extends foo {

pubvar $mystuff;

}

$a = new foo();
$a->setmyfoo2(5);
echo $a->getmyfoo2();

$b = new bar();
$b->setmyfoo2(10);
$b->setmystuff(20);

The point here is that pubvar automatically creates get* and set*.. As
far as overloading, etc is concerned, there would be no need to worry
about it -- the point of these functions is not to overload them (they
should simply be used to get and set member variables)... 

John

|-Original Message-
|From: Shane Caraveo [mailto:shane@;caraveo.com] 
|Sent: Tuesday, November 12, 2002 10:04 PM
|To: Alan Knowles
|Cc: [EMAIL PROTECTED]
|Subject: Re: [PHP-DEV] prototypes for getters and setters.
|
|
|Alan Knowles wrote:
|
|> Shane Caraveo wrote:
|>
|> >>
|> >>
|> >> Anyway before I get carried away and actually test this :) -
|> anybody got
|> >> any thoughts.
|> >>
|> >> Regards
|> >> Alan
|> >
|> >
|> >
|> >
|> > What's wrong with how overload does this?
|>
|>
|> it has a slight downside in clarity of code - eg. where is that 
|> method..
|>
|But it (overload) also does not introduce new syntax, requires no 
|changes to the engine, is genericly overrideable in extensions, etc. 
|etc. etc.
|
|Shane
|
|
|-- 
|PHP Development Mailing List 
|To unsubscribe, visit: http://www.php.net/unsub.php
|
|


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] mbstring and 4.3.0

[Yasuo Ohgaki]

Andrei Zmievski wrote:

I very much agree and am extremly reluctant to have mbstring enabled by
default, even though it is a very promising extension.


I can change my mind only if someone writes smart module loader that
detects module dependency. Otherwise, it's just confusing.
i.e. undefined symbol errors from modules depend on mbstring.
PHP dies badly with it obviously. Disabling it is the same as
asking for troubles.

I'm 0 iff there is smart loader patch.

--
Yasuo Ohgaki


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] mbstring and 4.3.0

[Andrei Zmievski]

On Tue, 12 Nov 2002, Ilia A. wrote:
> mbstring has many dedicated developers whom are doing excellent maintaining 
> and upgrading this extension. Which at the moment makes mbstring very much a 
> work in progress, there is hardly a day without at least one or two CVS 
> commits to it. Since this is a work in progress, it is simply not safe to 
> enable it by default if we want to claim any sort of stability for 4.3.0 
> release. There is a chance it'll work out, but IMHO there is even a greater 
> chance it will cause problems like it did in 4.2.3 with mangling of POST 
> requests, 4.3.0 will have more then enough new stuff as is.
> Perhaps by the next major release, mbstring will be a lot more mature and 
> thoroughly tested in production enviroment. At that point we can discuss this 
> issue again and consider whether this extension has merit for most users and 
> based on that decide whether or not to enable it by default.

I very much agree and am extremly reluctant to have mbstring enabled by
default, even though it is a very promising extension.

-Andrei   http://www.gravitonic.com/

"When I get a little money, I buy books;
 and if any is left I buy food and clothes." -- Erasmus

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] mbstring and 4.3.0

[Yasuo Ohgaki]

Jani Taskinen wrote:

   
   Oh, I forgot: How many bug reports have we got so
   far for that fuckup with 4.2.3 ??? I _REALLY_ don't want
   to see another wave of those for 4.3.0..

Do you mean array input handling bug?
It's not mbstring developers' fault.

--
Yasuo Ohgaki



On Wed, 13 Nov 2002, Marcus Börger wrote:



At 23:56 12.11.2002, Ilia A. wrote:


Since I've gotten involved in this conversation would like to add my opinion
to the tally. I too believe that at least at this point, the mbstring
extension should not be enabled by default.
There are two reasons for this decision:

1) Majority of PHP users do not require this functionality. Most PHP programs
are developed with non-multibyte languages in mind and mbstring only adds
unnecessary overhead. People who need it can easily enable it or ask their
ISPs to enable it, if they had done so already.


NO. Most people do not have the choice and ISPs usually take the default.
If the default is not approriate they do not use it.
If you read the whole thread you find enough reasons how apps benefit from
mbstring and what could be easily achieved with languages like german.




2) mbstring extension is a fairly complex piece of code and iirc is the
youngest extension of this magnitude that is enabled by default. Although the
extension developers are very prompt at fixing bugs, the fact they need to do
this fairly frequently, at least to me, implies that the extension is not yet
mature enough to be enabled by default. Also, judging by the number of
changes in the CVS to the extension, a lot of new functionality was added to
the extension recently and has not been tested outside the pre process. Maybe
by next PHP release is made, it will be better tested and more stable.

Ilia


Ok there are some problems and that is the backside of it: Some of us
implement new functionality and some merge code from the original development
tree. In other words: Maybe we should slow down or even stop feature 
development
until 4.3 is out After php 4.3 we hope the new implementation can be used.

As long as function overloading isn't used there is no harm from mbstring 
(disable
is the default). And some extra bytes shouldn't affect anybody today. If 
you say
most apps are not designed to use mbstring then it's nice that all those 
could try
mbstring which would like to. So we can get feedback. As long as it isn't 
default
there will be none or only little feedback.

The stability is very high and we have many *.phpt tests to help us find 
failures
and make it even more stable.

marcus








--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: ODBTP, a possible solution for MS-SQL and other databases

[Daniel Swarbrick]

Could this provide the functionality of an ODBC to ODBC bridge, if one used
the Win32 client library?

We have a requirement for an IIS webserver in a DMZ to talk to an ODBC
database on a Windows 2000 server in the trusted network.

I know there is already an ODBC-ODBC bridge commercial package, but it's a
tad expensive.

"Robert Twitty" <[EMAIL PROTECTED]> wrote in message
news:00aa01c28296$aeb10fe0$9b00a8c0@;bobawa...
> Hello
>
> ODBTP consists of a Windows NT / 2000 service application, an ODBTP client
> library that can be used to create  Win32 or UNIX clients,  and a PHP
> extension module that was created with the library.   ODBTP has the
> following features:
>



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] mbstring and 4.3.0

[Ilia A.]

On November 12, 2002 09:42 pm, Marcus Börger wrote:
> At 23:56 12.11.2002, Ilia A. wrote:
> >Since I've gotten involved in this conversation would like to add my
> > opinion to the tally. I too believe that at least at this point, the
> > mbstring extension should not be enabled by default.
> >There are two reasons for this decision:
> >
> >1) Majority of PHP users do not require this functionality. Most PHP
> > programs are developed with non-multibyte languages in mind and mbstring
> > only adds unnecessary overhead. People who need it can easily enable it
> > or ask their ISPs to enable it, if they had done so already.
>
> NO. Most people do not have the choice and ISPs usually take the default.
> If the default is not approriate they do not use it.

Through the course of my work I have to deal with many ISPs from all over the 
world, of all sizes. In my experience over 60% of ISPs have non-default PHP 
configuration. And most of the remaining 40% are more then willing to add 
additional extension(s), especially if those extensions do not require 
external libraries.
Keep in mind most ISPs will not upgrade to 4.3.0 and will most likely wait for 
a few releases past 4.3.0 to upgrade. 

> If you read the whole thread you find enough reasons how apps benefit from
> mbstring and what could be easily achieved with languages like german.

Any extension is useful if it was not the author(s) would not have spent time 
and effort writing it. The fact it is useful, does not automatically imply we 
should enable it by default. The question on the agenda wether ever single 
user who upgrades needs to have mbstring enabled by default. My belief that 
unless majority of PHP users will benefit from this extension we should not 
enable it by default. All the arguments in favor had not convinced me that 
this would be the case.

> >2) mbstring extension is a fairly complex piece of code and iirc is the
> >youngest extension of this magnitude that is enabled by default. Although
> > the extension developers are very prompt at fixing bugs, the fact they
> > need to do this fairly frequently, at least to me, implies that the
> > extension is not yet mature enough to be enabled by default. Also,
> > judging by the number of changes in the CVS to the extension, a lot of
> > new functionality was added to the extension recently and has not been
> > tested outside the pre process. Maybe by next PHP release is made, it
> > will be better tested and more stable.
> >
> >Ilia
>
> Ok there are some problems and that is the backside of it: Some of us
> implement new functionality and some merge code from the original
> development tree. In other words: Maybe we should slow down or even stop
> feature development
> until 4.3 is out After php 4.3 we hope the new implementation can be
> used.
>
> As long as function overloading isn't used there is no harm from mbstring
> (disable
> is the default). And some extra bytes shouldn't affect anybody today. If
> you say
> most apps are not designed to use mbstring then it's nice that all those
> could try
> mbstring which would like to. So we can get feedback. As long as it isn't
> default
> there will be none or only little feedback.
>
> The stability is very high and we have many *.phpt tests to help us find
> failures
> and make it even more stable.

mbstring has many dedicated developers whom are doing excellent maintaining 
and upgrading this extension. Which at the moment makes mbstring very much a 
work in progress, there is hardly a day without at least one or two CVS 
commits to it. Since this is a work in progress, it is simply not safe to 
enable it by default if we want to claim any sort of stability for 4.3.0 
release. There is a chance it'll work out, but IMHO there is even a greater 
chance it will cause problems like it did in 4.2.3 with mangling of POST 
requests, 4.3.0 will have more then enough new stuff as is.
Perhaps by the next major release, mbstring will be a lot more mature and 
thoroughly tested in production enviroment. At that point we can discuss this 
issue again and consider whether this extension has merit for most users and 
based on that decide whether or not to enable it by default.

Ilia

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] mbstring and 4.3.0

[Marcus Börger]

At 04:11 13.11.2002, Jani Taskinen wrote:


Since when have we started to use users as guinea-pigs
for testing EXPERIMENTAL extensions without them even
really knowing about it?!!


mbstring is not EXPERIMENTAL and i said let them try it. That
does not mean test it. We think it works .


You can't FORCE anybody to use it. 99% of apps out there
DO NO NEED IT..get it?? (they've managed without it very long time..)

--Jani


Yes they lived without correct display of characters because there was
no solution. For example i would like to send german umlauts even when
someone has another charset installation on his machine. With mbstring
this is easy.





On Wed, 13 Nov 2002, Marcus Börger wrote:

>At 23:56 12.11.2002, Ilia A. wrote:
>>Since I've gotten involved in this conversation would like to add my 
opinion
>>to the tally. I too believe that at least at this point, the mbstring
>>extension should not be enabled by default.
>>There are two reasons for this decision:
>>
>>1) Majority of PHP users do not require this functionality. Most PHP 
programs
>>are developed with non-multibyte languages in mind and mbstring only adds
>>unnecessary overhead. People who need it can easily enable it or ask their
>>ISPs to enable it, if they had done so already.
>
>NO. Most people do not have the choice and ISPs usually take the default.
>If the default is not approriate they do not use it.
>If you read the whole thread you find enough reasons how apps benefit from
>mbstring and what could be easily achieved with languages like german.
>
>
>>2) mbstring extension is a fairly complex piece of code and iirc is the
>>youngest extension of this magnitude that is enabled by default. 
Although the
>>extension developers are very prompt at fixing bugs, the fact they need 
to do
>>this fairly frequently, at least to me, implies that the extension is 
not yet
>>mature enough to be enabled by default. Also, judging by the number of
>>changes in the CVS to the extension, a lot of new functionality was 
added to
>>the extension recently and has not been tested outside the pre process. 
Maybe
>>by next PHP release is made, it will be better tested and more stable.
>>
>>Ilia
>
>Ok there are some problems and that is the backside of it: Some of us
>implement new functionality and some merge code from the original 
development
>tree. In other words: Maybe we should slow down or even stop feature
>development
>until 4.3 is out After php 4.3 we hope the new implementation can be 
used.
>
>As long as function overloading isn't used there is no harm from mbstring
>(disable
>is the default). And some extra bytes shouldn't affect anybody today. If
>you say
>most apps are not designed to use mbstring then it's nice that all those
>could try
>mbstring which would like to. So we can get feedback. As long as it isn't
>default
>there will be none or only little feedback.
>
>The stability is very high and we have many *.phpt tests to help us find
>failures
>and make it even more stable.
>
>marcus
>
>
>

--
<- For Sale! ->


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] mbstring and 4.3.0

[Jani Taskinen]

   
   Oh, I forgot: How many bug reports have we got so
   far for that fuckup with 4.2.3 ??? I _REALLY_ don't want
   to see another wave of those for 4.3.0..
   
   --Jani
   


On Wed, 13 Nov 2002, Marcus Börger wrote:

>At 23:56 12.11.2002, Ilia A. wrote:
>>Since I've gotten involved in this conversation would like to add my opinion
>>to the tally. I too believe that at least at this point, the mbstring
>>extension should not be enabled by default.
>>There are two reasons for this decision:
>>
>>1) Majority of PHP users do not require this functionality. Most PHP programs
>>are developed with non-multibyte languages in mind and mbstring only adds
>>unnecessary overhead. People who need it can easily enable it or ask their
>>ISPs to enable it, if they had done so already.
>
>NO. Most people do not have the choice and ISPs usually take the default.
>If the default is not approriate they do not use it.
>If you read the whole thread you find enough reasons how apps benefit from
>mbstring and what could be easily achieved with languages like german.
>
>
>>2) mbstring extension is a fairly complex piece of code and iirc is the
>>youngest extension of this magnitude that is enabled by default. Although the
>>extension developers are very prompt at fixing bugs, the fact they need to do
>>this fairly frequently, at least to me, implies that the extension is not yet
>>mature enough to be enabled by default. Also, judging by the number of
>>changes in the CVS to the extension, a lot of new functionality was added to
>>the extension recently and has not been tested outside the pre process. Maybe
>>by next PHP release is made, it will be better tested and more stable.
>>
>>Ilia
>
>Ok there are some problems and that is the backside of it: Some of us
>implement new functionality and some merge code from the original development
>tree. In other words: Maybe we should slow down or even stop feature 
>development
>until 4.3 is out After php 4.3 we hope the new implementation can be used.
>
>As long as function overloading isn't used there is no harm from mbstring 
>(disable
>is the default). And some extra bytes shouldn't affect anybody today. If 
>you say
>most apps are not designed to use mbstring then it's nice that all those 
>could try
>mbstring which would like to. So we can get feedback. As long as it isn't 
>default
>there will be none or only little feedback.
>
>The stability is very high and we have many *.phpt tests to help us find 
>failures
>and make it even more stable.
>
>marcus
>
>
>

-- 
<- For Sale! ->


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] mbstring and 4.3.0

[Jani Taskinen]

Since when have we started to use users as guinea-pigs
for testing EXPERIMENTAL extensions without them even
really knowing about it?!!

You can't FORCE anybody to use it. 99% of apps out there
DO NO NEED IT..get it?? (they've managed without it very long time..)

--Jani



On Wed, 13 Nov 2002, Marcus Börger wrote:

>At 23:56 12.11.2002, Ilia A. wrote:
>>Since I've gotten involved in this conversation would like to add my opinion
>>to the tally. I too believe that at least at this point, the mbstring
>>extension should not be enabled by default.
>>There are two reasons for this decision:
>>
>>1) Majority of PHP users do not require this functionality. Most PHP programs
>>are developed with non-multibyte languages in mind and mbstring only adds
>>unnecessary overhead. People who need it can easily enable it or ask their
>>ISPs to enable it, if they had done so already.
>
>NO. Most people do not have the choice and ISPs usually take the default.
>If the default is not approriate they do not use it.
>If you read the whole thread you find enough reasons how apps benefit from
>mbstring and what could be easily achieved with languages like german.
>
>
>>2) mbstring extension is a fairly complex piece of code and iirc is the
>>youngest extension of this magnitude that is enabled by default. Although the
>>extension developers are very prompt at fixing bugs, the fact they need to do
>>this fairly frequently, at least to me, implies that the extension is not yet
>>mature enough to be enabled by default. Also, judging by the number of
>>changes in the CVS to the extension, a lot of new functionality was added to
>>the extension recently and has not been tested outside the pre process. Maybe
>>by next PHP release is made, it will be better tested and more stable.
>>
>>Ilia
>
>Ok there are some problems and that is the backside of it: Some of us
>implement new functionality and some merge code from the original development
>tree. In other words: Maybe we should slow down or even stop feature 
>development
>until 4.3 is out After php 4.3 we hope the new implementation can be used.
>
>As long as function overloading isn't used there is no harm from mbstring 
>(disable
>is the default). And some extra bytes shouldn't affect anybody today. If 
>you say
>most apps are not designed to use mbstring then it's nice that all those 
>could try
>mbstring which would like to. So we can get feedback. As long as it isn't 
>default
>there will be none or only little feedback.
>
>The stability is very high and we have many *.phpt tests to help us find 
>failures
>and make it even more stable.
>
>marcus
>
>
>

-- 
<- For Sale! ->


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] prototypes for getters and setters.

[Shane Caraveo]

Alan Knowles wrote:


Shane Caraveo wrote:

>>
>>
>> Anyway before I get carried away and actually test this :) - 
anybody got
>> any thoughts.
>>
>> Regards
>> Alan
>
>
>
>
> What's wrong with how overload does this?


it has a slight downside in clarity of code - eg. where is that method..

But it (overload) also does not introduce new syntax, requires no 
changes to the engine, is genericly overrideable in extensions, etc. 
etc. etc.

Shane


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] prototypes for getters and setters.

[Alan Knowles]

Shane Caraveo wrote:




Anyway before I get carried away and actually test this :) - anybody got
any thoughts.

Regards
Alan




What's wrong with how overload does this? 

it has a slight downside in clarity of code - eg. where is that method.. 



SHane





--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Proto void and return values...

[Maxim Maletsky]

Most of them (70% ?) are actually having wrong protos in docs.

I refer to the ones that return boolean (like phpinfo() for instance)
but documented as returning an integer. This is not really a huge issue,
but does make confusion because of the kind of functions that MUST
return true of false (is_link() for example). 

-- 
Maxim Maletsky
[EMAIL PROTECTED]


On 12 Nov 2002 22:59:50 +0100 Zak Greant <[EMAIL PROTECTED]> wrote:

> On Tue, 2002-11-12 at 20:25, David Brown wrote:
> > On Tue, Nov 12, 2002 at 02:16:41PM -0500, David Brown wrote:
> > | Hi everyone:
> > | 
> > | For functions prototyped as returning void, return values seem to be applied
> > | at random. Some functions, such as trigger_error/user_error, srand, ob_start,
> > | and phpinfo, use RETURN_TRUE. The vast majority of these functions just fall
> > | through, implicitly returning NULL to userland.
> > 
> > Or perhaps I'v just thought about this entirely too long. Is it possible
> > that the prototypes are just wrong in the documentation?
> 
>   Bingo! :) (or at least, that is my belief - I might be wrong :)
> 
>   --zak
> 
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
> 


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] mbstring and 4.3.0

[Marcus Börger]

At 23:56 12.11.2002, Ilia A. wrote:

Since I've gotten involved in this conversation would like to add my opinion
to the tally. I too believe that at least at this point, the mbstring
extension should not be enabled by default.
There are two reasons for this decision:

1) Majority of PHP users do not require this functionality. Most PHP programs
are developed with non-multibyte languages in mind and mbstring only adds
unnecessary overhead. People who need it can easily enable it or ask their
ISPs to enable it, if they had done so already.


NO. Most people do not have the choice and ISPs usually take the default.
If the default is not approriate they do not use it.
If you read the whole thread you find enough reasons how apps benefit from
mbstring and what could be easily achieved with languages like german.



2) mbstring extension is a fairly complex piece of code and iirc is the
youngest extension of this magnitude that is enabled by default. Although the
extension developers are very prompt at fixing bugs, the fact they need to do
this fairly frequently, at least to me, implies that the extension is not yet
mature enough to be enabled by default. Also, judging by the number of
changes in the CVS to the extension, a lot of new functionality was added to
the extension recently and has not been tested outside the pre process. Maybe
by next PHP release is made, it will be better tested and more stable.

Ilia


Ok there are some problems and that is the backside of it: Some of us
implement new functionality and some merge code from the original development
tree. In other words: Maybe we should slow down or even stop feature 
development
until 4.3 is out After php 4.3 we hope the new implementation can be used.

As long as function overloading isn't used there is no harm from mbstring 
(disable
is the default). And some extra bytes shouldn't affect anybody today. If 
you say
most apps are not designed to use mbstring then it's nice that all those 
could try
mbstring which would like to. So we can get feedback. As long as it isn't 
default
there will be none or only little feedback.

The stability is very high and we have many *.phpt tests to help us find 
failures
and make it even more stable.

marcus


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] prototypes for getters and setters.

[Shane Caraveo]

Anyway before I get carried away and actually test this :) - anybody got
any thoughts.

Regards
Alan



What's wrong with how overload does this?

SHane


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Photos from the Conference

[Maxim Maletsky]

I put some up. Whoever is interested:
http://www.php-conference.de/gallery/album10


-- 
Maxim Maletsky
[EMAIL PROTECTED]


On Thu, 7 Nov 2002 13:25:50 +0100 Björn Schotte <[EMAIL PROTECTED]> wrote:

> * Maxim Maletsky wrote:
> > But hey! Where is me? You got no photos of me there :) How come?
> 
> Perhaps at http://www.phpconference.de/gallery/ ? (Those people
> who made photos should upload them there)
> 
> -- 
> 35 Kundenportale mit mehreren tausend Nutzern erstellen.
> Bei geringen Kosten und einer großen Anzahl an Modulen
> (DMS, CMS, CRM, Community-Funktionen). Wie das geht?
> => http://testthesystem.com/ *  [EMAIL PROTECTED]
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
> 


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] prototypes for getters and setters.

[Marcus Börger]

Very interesting and another syntax suggestion:

var $variable ( getter, setter[, default] );
i havent't took a look in ther parser scripts yet but this seems easier.

Anyway the problem is that you cannot have a setter without a getter.
What about
var $variable ( [get=getter] [set=setter] [default=value] );
or
var $variable [= value] ( [get=getter] [set=setter] );

optionally we could have array support like delphi

var $variable[] ( [get=getter] [set=setter] );
where gettter/setter are a functions whos first parameter is the index

value function getVariable(index)
value function setVariable(index, value);

marcus

At 02:31 13.11.2002, Alan Knowles wrote:

Thanks to a little chat (and a  few beers) with Zak at the conference, I 
got wondering if this syntax would be a sensible addition...

The principle is to enable rapid prototyping of getter and setter methods.

class something {
   var getBanana setBanana $banana = 12;
   var getOrange $orange =1;
   function setOrange($value) {
   if ($value == $this->banana) {
   echo "mmh banana's and oranges are the same";
   }
   }
}
$t = new something;
echo $t->getBanana();
echo $t->setBanana(3);
echo $t->setOrange(3);

syntax:
  var [getter method] [setter method] $variable .;

or any other ideas
  var (getBanana, setBanana) $banana

  function var getBanana, setBanana for  $banana = '12'; // nice bit of 
token recycling.

  var use getBanana and setBanana for $banana = '12';


from a quick play with zend_language_parser.y the additionall code to

class_variable_decleration:

would look a bit like this...


| is_reference T_STRING T_VARIABLE  '=' static_scalar{
   znode tmp;
   znode tmpthis;
   znode tmpfinalval;

   zend_copy_value(tmpthis, 'this', 5);
   tmpthis->type = IS_STRING;

   zend_do_declare_property(&$3, &$6 TSRMLS_CC);
   function.u.opline_num = CG(zend_lineno);
   zend_do_begin_function_declaration(&function, &$3, 1, 
$2.op_type TSRMLS_CC); }

   # get the 'this' part..
   zend_do_fetch_globals(&tmpthis TSRMLS_CC);
   zend_do_begin_variable_parse(TSRMLS_C);
   fetch_simple_variable(&tmp, &tmpthis, 1 TSRMLS_CC);

   zend_do_fetch_property(&tmpfinalval, &tmp, &$6 TSRMLS_CC);}

zend_do_return(&tmpfinalval, 1 TSRMLS_CC);
   zend_do_end_function_declaration(&$1 TSRMLS_CC);

   }

Anyway before I get carried away and actually test this :) - anybody got 
any thoughts.

Regards
Alan


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] prototypes for getters and setters.

[John Coggeshall]

|syntax:
|   var [getter method] [setter method] $variable .;

I think this syntax looks pretty interesting. It would allow the
developer to create get/set if desired and doesn't look too strange
either..

I'd like to see it in action myself :)

John


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] prototypes for getters and setters.

[Alan Knowles]

Thanks to a little chat (and a  few beers) with Zak at the conference, I 
got wondering if this syntax would be a sensible addition...

The principle is to enable rapid prototyping of getter and setter 
methods.

class something {
   var getBanana setBanana $banana = 12;
   var getOrange $orange =1;
   function setOrange($value) {
   if ($value == $this->banana) {
   echo "mmh banana's and oranges are the same";  
   }
   }
}
$t = new something;
echo $t->getBanana();
echo $t->setBanana(3);
echo $t->setOrange(3);

syntax:
  var [getter method] [setter method] $variable .;

or any other ideas
  var (getBanana, setBanana) $banana

  function var getBanana, setBanana for  $banana = '12'; // nice bit of 
token recycling.

  var use getBanana and setBanana for $banana = '12';


from a quick play with zend_language_parser.y the additionall code to

class_variable_decleration:

would look a bit like this...


| is_reference T_STRING T_VARIABLE  '=' static_scalar{
   znode tmp;
   znode tmpthis; 
   znode tmpfinalval;

   zend_copy_value(tmpthis, 'this', 5);
   tmpthis->type = IS_STRING;

   zend_do_declare_property(&$3, &$6 TSRMLS_CC);
   function.u.opline_num = CG(zend_lineno);
   zend_do_begin_function_declaration(&function, &$3, 1, 
$2.op_type TSRMLS_CC); }
  
   # get the 'this' part..
   zend_do_fetch_globals(&tmpthis TSRMLS_CC);
   zend_do_begin_variable_parse(TSRMLS_C);
   fetch_simple_variable(&tmp, &tmpthis, 1 TSRMLS_CC);

   zend_do_fetch_property(&tmpfinalval, &tmp, &$6 TSRMLS_CC);}

zend_do_return(&tmpfinalval, 1 TSRMLS_CC);
   zend_do_end_function_declaration(&$1 TSRMLS_CC);
  
   }

Anyway before I get carried away and actually test this :) - anybody got 
any thoughts.

Regards
Alan


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] mbstring and 4.3.0

[Yasuo Ohgaki]

Mike Robinson wrote:

Jani Taskinen writes:



   I must (still) agree. +1 for making it disabled for now..
   (people who need it, already know to use 
--enable-mbstring with 4.2.3)


Exactly.
It should remain off by default until it's solid.


Guys, please comment when you use it actually.
i.e. mention unsolid things, problems, etc.

Bug reports are welcome.

--
Yasuo Ohgaki


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] mbstring and 4.3.0

[Mike Robinson]

Jani Taskinen writes:

> I must (still) agree. +1 for making it disabled for now..
> (people who need it, already know to use 
> --enable-mbstring with 4.2.3)

Exactly.
It should remain off by default until it's solid.

Regards
Mike Robinson


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] mbstring and 4.3.0

[Yasuo Ohgaki]

Moriyoshi Koizumi wrote:

Hi,

Thanks for the report.
Although I found a bug in the overloading code, I wonder why the mail() 
function entry was not found on RINIT. Any insights?

If sendmail binary cannot be found at configure time, mail() may not
be compiled in PHP under UNIX like OS :(

IMO, we should always compile mail() function.
Distributors sometimes release PHP packages (i.e. RPM) w/o mail()
sometimes.

--
Yasuo Ohgaki



Moriyoshi

"Ilia A." <[EMAIL PROTECTED]> wrote:



On November 7, 2002 10:04 am, Andrei Zmievski wrote:


At the PHP Conference in Germany several of us have discussed the
current state of mbstring and there was a proposal to not have it
enabled by default for 4.3.0 release. It seems that the extension
attempts to do "magic" stuff by overloading functions in the executor
globals and, as Thies said, that could be dangerous. Also, doesn't it
affect run-tests.php script currently?



On the note of overloading done by mbstring, it appears this behavior is not 
entirely stable. On at least one test system (Sun OS 5.9) it causes crashes 
and overruns by using the test script in the test suite.
Ex:
sapi/cli/php -d "mbstring.func_overload=1" -r ''
Unknown(0) : Fatal error - (null)() [http://www.php.net/ref.mbstring]: 
mbstring couldn't find function mail.
Could not startup.
[Tue Nov 12 21:01:33 2002]  Script:  '-'
---
php4/Zend/zend_execute.h(44) : Block 0x001FB640 status:
Beginning:  Overrun (magic=0x001FE7F8, expected=0x7312F8DC)
 End:  Unknown
---

The test script itself (ext/mbstring/tests/overload.phpt) causes a 
segmentation fault. Here is a back trace:
#0  0x001528f8 in shutdown_memory_manager (silent=1, clean_cache=1) at 
php4/Zend/zend_alloc.c:461
#1  0x0011d944 in php_module_shutdown () at php4/main/main.c:1219
#2  0x0018d8d0 in main (argc=39, argv=0xffbffa74) at 
php4/sapi/cli/php_cli.c:761

Ilia

--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php






--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: GD filters done patch available

[Pierre-Alain Joye]

On Wed, 13 Nov 2002 01:40:52 +0100
"Peter Neuman" <[EMAIL PROTECTED]> wrote:

> Hi,
> 
> "Pierre-Alain Joye" <[EMAIL PROTECTED]>:
> 
> > GD filters are done and patch against current cvs available at
> > http://www.pearfr.org/phpgd/filters/
> >
> > Feedbacks, comments welcome
> 
> Very nice :-)

thank's :)

pa

ps: sorry for double posts

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: GD filters done patch available

[nicos]

Very nice.

Well the nicest is the girl too.

--

M.CHAILLAN Nicolas
[EMAIL PROTECTED]
www.WorldAKT.com Hébergement de sites internets.

"Peter Neuman" <[EMAIL PROTECTED]> a écrit dans le message de news:
[EMAIL PROTECTED]
> Hi,
>
> "Pierre-Alain Joye" <[EMAIL PROTECTED]>:
>
> > GD filters are done and patch against current cvs available at
> > http://www.pearfr.org/phpgd/filters/
> >
> > Feedbacks, comments welcome
>
> Very nice :-)
>
> Peter Neuman
>
>



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] GD filters done patch available

[Pierre-Alain Joye]

On Tue, 12 Nov 2002 22:17:06 +0100
Pierre-Alain Joye <[EMAIL PROTECTED]> wrote:

> Hello,
> 
> GD filters are done and patch against current cvs available at
> http://www.pearfr.org/phpgd/filters/
> 
> Feedbacks, comments welcome

I uploaded a new patch, I forgot the CS and fix 2 memory leaks :)

pa

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: GD filters done patch available

[Peter Neuman]

Hi,

"Pierre-Alain Joye" <[EMAIL PROTECTED]>:

> GD filters are done and patch against current cvs available at
> http://www.pearfr.org/phpgd/filters/
>
> Feedbacks, comments welcome

Very nice :-)

Peter Neuman



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/snmp CREDITS php_snmp.hsnmp.c

[Jani Taskinen]

Maybe it would be good idea to do something like
LDAP extension does? ie. have something similar to ldap_set_option()
to set the protocol version to be used? And have same
functions and thus not pollute the function namespace anymore?

iirc, the snmp command line tools have an option to select
which protocol version to use?

--Jani


On Tue, 12 Nov 2002, Harrie Hazewinkel wrote:

>
>
>--On Tuesday, November 12, 2002 10:42 PM +0100 Derick Rethans 
><[EMAIL PROTECTED]> wrote:
>
>> On Tue, 12 Nov 2002, Harrie Hazewinkel wrote:
>>
>>> >> These function names don't follow the PHP standards, I think we should
>>> >> definitely come up with better names.
>>> >
>>> > I agree. what's wrong with snmp_get, snmp_walk, and so on?
>>>
>>> I believe it is neccessary to have the 'v3' in the name. It makes very
>>> clear to people that it is for snmpv3 and not any opther snmp version.
>>>
>>> SNMPv3 is the protocol version that has security support and is known
>>> as under SNMPv3 by many people.
>>
>> But what use does it have in it's name? We don't have PGsqlV6 and
>> pgsqlv7_, or mysqlv3_ and mysqlv4_ (or take the gd functions).
>
>Again I believe there is a difference between a package version number
>and this protocol. I do not believe that snmp_get is an improvement over
>snmpv3get for instance.
>
>Although, I admit I have been thinking of using the used example snmp_get,
>but then I need to add a version number as parameter. This would allow
>as well the existing snmpget (for SNMPv1) to be combined with snmpv3get
>(for SNMPv3). However, I have kept it simple for the moment and attempted
>to make it as easy as possible to upgrade scripts to SNMPv3.
>And on top of it, also providing a quick and well understood recognition
>of it.
>
>Also SNMPv3 is a full standard and that version number is not likely
>(and hopefully) about to change.
>
>>
>>>
>>> Anyway, where would be the function name guide lines on the website.
>>> I cannot find it and a pointer would be appreciated.
>>
>> See the CODING_STANDARDS file in the root of the php4/ CVS module.
>
>THanks, I will check it out.
>
>>
>> Derick
>>
>> --
>>
>> -
>> --  Derick Rethans
>> http://derickrethans.nl/   JDI Media Solutions
>> --[ if you hold a unix shell to your ear, do you hear the c?
>> ]-
>>
>>
>
>
>
>Harrie
>
>Internet Management Consulting
>mailto: [EMAIL PROTECTED]   http://www.lisanza.net/
>
>Author of MOD-SNMP, enabling SNMP management the Apache HTTP server
>
>

-- 
<- For Sale! ->


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] GD filters done patch available

[Pierre-Alain Joye]

On Tue, 12 Nov 2002 22:17:06 +0100
Pierre-Alain Joye <[EMAIL PROTECTED]> wrote:

> Hello,
> 
> GD filters are done and patch against current cvs available at
> http://www.pearfr.org/phpgd/filters/
> 
> Feedbacks, comments welcome

I uploaded a new patch, I forgot the CS and fix 2 memory leaks :)

pa

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] mbstring and 4.3.0

[Jani Taskinen]

On Tue, 12 Nov 2002, Ilia A. wrote:

>Since I've gotten involved in this conversation would like to add my opinion 
>to the tally. I too believe that at least at this point, the mbstring 
>extension should not be enabled by default.
>There are two reasons for this decision:
>
>1) Majority of PHP users do not require this functionality. Most PHP programs 
>are developed with non-multibyte languages in mind and mbstring only adds 
>unnecessary overhead. People who need it can easily enable it or ask their 
>ISPs to enable it, if they had done so already.
>
>2) mbstring extension is a fairly complex piece of code and iirc is the 
>youngest extension of this magnitude that is enabled by default. Although the 
>extension developers are very prompt at fixing bugs, the fact they need to do 
>this fairly frequently, at least to me, implies that the extension is not yet 
>mature enough to be enabled by default. Also, judging by the number of 
>changes in the CVS to the extension, a lot of new functionality was added to 
>the extension recently and has not been tested outside the pre process. Maybe 
>by next PHP release is made, it will be better tested and more stable.


I must (still) agree. +1 for making it disabled for now..
(people who need it, already know to use --enable-mbstring with 4.2.3)


--Jani



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Sybase_ct and tli lib

[Timm Friebe]

On Tue, 2002-11-12 at 23:20, Brian Foddy wrote:
> The following is not really worthy of reporting an official bug,
> but still worthy of at least comment and notice.
> 
> On Solaris 2.8 using Sybase OCS-12, the default build
> scripts for PHP 4.2.3 will not link in the tli library.

Never heard of tli before, and these three systems don't even have one
(PHP working fine on each of them):

FreeBSD, Sybase 11.0.3.3:
thekid@friebes:/usr/local/sybase/lib > ls -al *.so
-r-xr-xr-x  1 sybase  1002  303559 Mar 22  2000 libcomn.so
-r-xr-xr-x  1 sybase  1002   50771 Mar 22  2000 libcs.so
-r-xr-xr-x  1 sybase  1002  352659 Mar 22  2000 libct.so
-r-xr-xr-x  1 sybase  10028297 Mar 22  2000 libinsck.so
-r-xr-xr-x  1 sybase  1002   31380 Mar 22  2000 libintl.so
-r-xr-xr-x  1 sybase  1002  691945 Mar 22  2000 libsybdb.so
-r-xr-xr-x  1 sybase  1002   78630 Mar 22  2000 libsybtcl.so

SuSE, Sybase 12.5:
cia:/opt/sybase-12.5/lib # ls -al *.so
-r-xr-xr-x   1 sybase   sybase 427075 Nov  7  2000 libcomn.so
-r-xr-xr-x   1 sybase   sybase  60633 Nov  7  2000 libcs.so
-r-xr-xr-x   1 sybase   sybase 488501 Nov  7  2000 libct.so
-r-xr-xr-x   1 sybase   sybase  10802 Nov  7  2000 libinsck.so
-r-xr-xr-x   1 sybase   sybase  32765 Nov  7  2000 libintl.so
-r-xr-xr-x   1 sybase   sybase 419115 Nov  7  2000 libsrv.so
-r-xr-xr-x   1 sybase   sybase 880462 Nov  7  2000 libsybdb.so
-r-xr-xr-x   1 sybase   sybase 178687 Nov  7  2000 libsybtcl.so

Debian, Sybase 11.9.2:
heuer1:/usr/opt/sybase-11.9.2/lib# ls -al *.so
-r-xr-xr-x1 root root 3703 Jun  1 21:55 examples.so
-r-xr-xr-x1 root root   398293 Jun  1 21:55 libcomn.so
-r-xr-xr-x1 root root55936 Jun  1 21:55 libcs.so
-r-xr-xr-x1 root root   441107 Jun  1 21:55 libct.so
-r-xr-xr-x1 root root10139 Jun  1 21:55 libinsck.so
-r-xr-xr-x1 root root31922 Jun  1 21:55 libintl.so
-r-xr-xr-x1 root root 6508 Jun  1 21:55 libssencode.so
-r-xr-xr-x1 root root   132363 Jun  1 21:55 libssfile.so
-r-xr-xr-x1 root root 8113 Jun  1 21:55 libsstasks6.so
-r-xr-xr-x1 root root  1361512 Jun  1 21:55 libsstools6.so
-r-xr-xr-x1 root root   782151 Jun  1 21:55 libsybdb.so
-r-xr-xr-x1 root root   156706 Jun  1 21:55 libsybtcl.so
-r-xr-xr-x1 root root 6260 Jun  1 21:55 sybsyesp.so
-r-xr-xr-x1 root root18237 Jun  1 21:55 xpsmsgs.so

> Those familiar with Sybase have probably stubbed their toes
> on this library several times before; I've certainly have.

I've never needed to include it, not on SuSE, not on Debian nor on
FreeBSD. Could you run a strings | grep "^Sybase" on libtli.so and send
me the output?

thekid@friebes:~ > strings /usr/local/sybase/lib/libct.so|grep "^Sybase"
Sybase Client-Library/10.0.4/P-FREE/FreeBSD Intel/FreeBSD 3.3-RELEASE
i386/1/Sat Mar 18 11:44:11 CET 2000
Sybase, Inc. 6475 Christie Avenue, Emeryville, CA 94608 USA.

[...]
> I found that without this library linked in, the web server
> would start (with sudo/suid) but the following error would be reported in
> the apache error log:
> 
> Open Client Message:
> Message number: LAYER = (5) ORIGIN = (3) SEVERITY = (5) NUMBER = (131)
> Message String: ct_init(): network packet layer: internal net library 
> error: Attempt to load protocol driver failed
> 
> And of course no Sybase connections would work.

This looks suspiciously like one of the problems the people where having
here:
http://dbforums.com/t518102.html
http://dbforums.com/archives/t50881.html

I also found this document (dated Dec. 30, 1999):
http://www.sybase.com/detail?id=1000925

Is there any chance you're lately upgraded your sybase installation?
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&threadm=agjh46%24gu0%241%40reader01.singnet.com.sg&rnum=3&prev=/groups%3Fq%3Derror:%2BAttempt%2Bto%2Bload%2Bprotocol%2Bdriver%2Bfailed%26hl%3Den%26lr%3D%26ie%3DUTF-8%26selm%3Dagjh46%2524gu0%25241%2540reader01.singnet.com.sg%26rnum%3D3
or
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&threadm=aps4uf%24jfp%241%40dcgate.bls.gov&rnum=1&prev=/groups%3Fq%3Dlibtli.so%26hl%3Den%26lr%3D%26ie%3DUTF-8%26selm%3Daps4uf%2524jfp%25241%2540dcgate.bls.gov%26rnum%3D1
might help then (links may be wrapped)

> When I linked in the tli library, everything thing ok.
> I've attached a simple diff of the sybase_ct/config.m4 that
> I used to get the tli library included.

It would give me linker errors:-)

> I will be the first to admit, I really don't know "why"
> this library (or its absense) causes this behavior,
> nor do I really fully understand what the lib is supposed to
> do.  If someone can explain it to me, please try.
> Otherwise, I just try to remember this error message
> is usually related to the presents/absense of the
> tli library.
> 
> Anyway I thought I would post this info in hopes it
> might lead to a better solution in the future.

I hope this helps. If it do

Re: [PHP-DEV] DBA and Win

[Marcus Börger]

At 00:07 13.11.2002, Edin Kadribasic wrote:

On Tuesday 12 November 2002 13:36, Marcus Börger wrote:
> Could someone with windows please add bundled flatfile
> and cdb support for ext/dba to the windows build?

Could you tell me which files need to be compiled and and which defines to be
set?

Edin


for cdb:
#define DBA_CDB 1
#define DBA_CDB_MAKE 1
#define DBA_CDB_BUILTIN 1
ext/dba/libcdb/cdb.c
ext/dba/libcdb/cdb_ame.c
ext/dba/libcdb/uint32.c
+corresponding header files

for flatfile:
#define DBA_FLATFILE 1
ext/dba/libflatfile/flatfile.c
+corresponding header files
ext/dba_flatfile.c

that's it & thanks marcus


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] mbstring and 4.3.0

[Ilia A.]

I've just tried the latest CVS, it still crashes, the backtrace is same as 
before.

Ilia

On November 12, 2002 05:21 pm, Moriyoshi Koizumi wrote:
> Oops, why didn't I notice such a trivial thing before asking a braindead
> question... Anyway I bet the problem should be gone by my patch that was
> just commited.
>
> Moriyoshi
>
> "Ilia A." <[EMAIL PROTECTED]> wrote:
> > On November 12, 2002 04:58 pm, Moriyoshi Koizumi wrote:
> > > Hi,
> > >
> > > Thanks for the report.
> > > Although I found a bug in the overloading code, I wonder why the mail()
> > > function entry was not found on RINIT. Any insights?
> >
> > It seems the mail() function is not avaliable on that system because
> > sendmail was not found on the system. The function mail() on unix systems
> > appears to be dependant on sendmail avaliablity or atleast something that
> > would cause the HAVE_SENDMAIL flag to be set.
> >
> > Ilia
> >
> > > Moriyoshi
> > >
> > > "Ilia A." <[EMAIL PROTECTED]> wrote:
> > > > On November 7, 2002 10:04 am, Andrei Zmievski wrote:
> > > > > At the PHP Conference in Germany several of us have discussed the
> > > > > current state of mbstring and there was a proposal to not have it
> > > > > enabled by default for 4.3.0 release. It seems that the extension
> > > > > attempts to do "magic" stuff by overloading functions in the
> > > > > executor globals and, as Thies said, that could be dangerous. Also,
> > > > > doesn't it affect run-tests.php script currently?
> > > >
> > > > On the note of overloading done by mbstring, it appears this behavior
> > > > is not entirely stable. On at least one test system (Sun OS 5.9) it
> > > > causes crashes and overruns by using the test script in the test
> > > > suite. Ex:
> > > > sapi/cli/php -d "mbstring.func_overload=1" -r ''
> > > > Unknown(0) : Fatal error - (null)()
> > > > [http://www.php.net/ref.mbstring]: mbstring couldn't find function
> > > > mail.
> > > > Could not startup.
> > > > [Tue Nov 12 21:01:33 2002]  Script:  '-'
> > > > ---
> > > > php4/Zend/zend_execute.h(44) : Block 0x001FB640 status:
> > > > Beginning:  Overrun (magic=0x001FE7F8, expected=0x7312F8DC)
> > > >   End:  Unknown
> > > > ---
> > > >
> > > > The test script itself (ext/mbstring/tests/overload.phpt) causes a
> > > > segmentation fault. Here is a back trace:
> > > > #0  0x001528f8 in shutdown_memory_manager (silent=1, clean_cache=1)
> > > > at php4/Zend/zend_alloc.c:461
> > > > #1  0x0011d944 in php_module_shutdown () at php4/main/main.c:1219
> > > > #2  0x0018d8d0 in main (argc=39, argv=0xffbffa74) at
> > > > php4/sapi/cli/php_cli.c:761
> > > >
> > > > Ilia
> > > >
> > > > --
> > > > PHP Development Mailing List 
> > > > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> > --
> > PHP Development Mailing List 
> > To unsubscribe, visit: http://www.php.net/unsub.php


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] w32api extesion

[Edin Kadribasic]

On Tuesday 12 November 2002 15:31, James Moore wrote:
> jmooreTue Nov 12 09:31:35 2002 EDT
>
>   Added files:
> /php4/ext/w32api  w32api_function_definition_parser.y
>   w32api_function_definition_scanner.l
>   w32api_type_definition_parser.y
>   w32api_type_definition_scanner.l

This does not compile on the snapshot machine. Please have a look at 
http://snaps.php.net/win32/compile.log for details. Could it be it's because 
I'm using very recent bison version (1.75)?

Edin


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] DBA and Win

[Edin Kadribasic]

On Tuesday 12 November 2002 13:36, Marcus Börger wrote:
> Could someone with windows please add bundled flatfile
> and cdb support for ext/dba to the windows build?

Could you tell me which files need to be compiled and and which defines to be 
set?

Edin


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Proto void and return values...

[Zak Greant]

On Tue, 2002-11-12 at 20:25, David Brown wrote:
> On Tue, Nov 12, 2002 at 02:16:41PM -0500, David Brown wrote:
> | Hi everyone:
> | 
> | For functions prototyped as returning void, return values seem to be applied
> | at random. Some functions, such as trigger_error/user_error, srand, ob_start,
> | and phpinfo, use RETURN_TRUE. The vast majority of these functions just fall
> | through, implicitly returning NULL to userland.
> 
> Or perhaps I'v just thought about this entirely too long. Is it possible
> that the prototypes are just wrong in the documentation?

  Bingo! :) (or at least, that is my belief - I might be wrong :)

  --zak


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PUT method support

[Zak Greant]

On Tue, 2002-11-12 at 14:14, Hartmut Holzgraefe wrote:
> 
> looks like this was a PHP3 only feature?
> 
> http://www.php.net/manual/sv/printwn/features.file-upload.put-method.php

  Yes - this never made it out of PHP 3.

  --zak


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] mbstring and 4.3.0

[Ilia A.]

Since I've gotten involved in this conversation would like to add my opinion 
to the tally. I too believe that at least at this point, the mbstring 
extension should not be enabled by default.
There are two reasons for this decision:

1) Majority of PHP users do not require this functionality. Most PHP programs 
are developed with non-multibyte languages in mind and mbstring only adds 
unnecessary overhead. People who need it can easily enable it or ask their 
ISPs to enable it, if they had done so already.

2) mbstring extension is a fairly complex piece of code and iirc is the 
youngest extension of this magnitude that is enabled by default. Although the 
extension developers are very prompt at fixing bugs, the fact they need to do 
this fairly frequently, at least to me, implies that the extension is not yet 
mature enough to be enabled by default. Also, judging by the number of 
changes in the CVS to the extension, a lot of new functionality was added to 
the extension recently and has not been tested outside the pre process. Maybe 
by next PHP release is made, it will be better tested and more stable.

Ilia


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] php4apache on win32 regex problem?

[Dave Viner]

has anyone seen this error on win32 php4apache?

Configuration: php4apache - Win32
Release_TS
Compiling...
mod_php4.c
..\..\main\php_regex.h(39) : fatal error C1083: Cannot open include file:
'regex.h': No such file or directory
php_apache.c
..\..\main\php_regex.h(39) : fatal error C1083: Cannot open include file:
'regex.h': No such file or directory
sapi_apache.c
..\..\main\php_regex.h(39) : fatal error C1083: Cannot open include file:
'regex.h': No such file or directory
Error executing cl.exe.

is there some cygwin package that I need to install in order to obtain the
regex.h header file ?

thanks
dave


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Sybase_ct and tli lib

[Brian Foddy]

The following is not really worthy of reporting an official bug,
but still worthy of at least comment and notice.

On Solaris 2.8 using Sybase OCS-12, the default build
scripts for PHP 4.2.3 will not link in the tli library.
Those familiar with Sybase have probably stubbed their toes
on this library several times before; I've certainly have.

When PHP is built and run using Apache 1.3.2x.  When the
web server is started as a real root user, everything works
fine.  However in our environment we don't have production root
access, so we have to use sudo or the SUID bit to start
the web server as root.

I found that without this library linked in, the web server
would start (with sudo/suid) but the following error would be reported in
the apache error log:

Open Client Message:
Message number: LAYER = (5) ORIGIN = (3) SEVERITY = (5) NUMBER = (131)
Message String: ct_init(): network packet layer: internal net library 
error: Attempt to load protocol driver failed

And of course no Sybase connections would work.

When I linked in the tli library, everything thing ok.
I've attached a simple diff of the sybase_ct/config.m4 that
I used to get the tli library included.

I will be the first to admit, I really don't know "why"
this library (or its absense) causes this behavior,
nor do I really fully understand what the lib is supposed to
do.  If someone can explain it to me, please try.
Otherwise, I just try to remember this error message
is usually related to the presents/absense of the
tli library.

Anyway I thought I would post this info in hopes it
might lead to a better solution in the future.

Thanks,
Brian

PS:  my configure line is:
./configure --with-apxs=/apps/soc/apache/bin/apxs \
--prefix=/apps/soc/apache/php4 --with-sybase-ct=/apps/soc/sybase/OCS-12_0 \
--enable-track-vars --with-config-file-path=/apps/soc/apache/php4 \
--enable-trans-sid --with-ldap



*** ext/sybase_ct/config.m4 Fri Nov 30 22:12:31 2001
***
*** 34,41 
  PHP_ADD_LIBRARY(ct,, SYBASE_CT_SHARED_LIBADD)
  PHP_ADD_LIBRARY(comn,, SYBASE_CT_SHARED_LIBADD)
  PHP_ADD_LIBRARY(intl,, SYBASE_CT_SHARED_LIBADD)

! SYBASE_CT_LIBS="-L$SYBASE_CT_LIBDIR -lcs -lct -lcomn -lintl"

  PHP_CHECK_LIBRARY(tcl, netg_errstr, [
PHP_ADD_LIBRARY(tcl,,SYBASE_CT_SHARED_LIBADD)
--- 34,42 
  PHP_ADD_LIBRARY(ct,, SYBASE_CT_SHARED_LIBADD)
  PHP_ADD_LIBRARY(comn,, SYBASE_CT_SHARED_LIBADD)
  PHP_ADD_LIBRARY(intl,, SYBASE_CT_SHARED_LIBADD)
+   PHP_ADD_LIBRARY(tli,, SYBASE_CT_SHARED_LIBADD) 

! SYBASE_CT_LIBS="-L$SYBASE_CT_LIBDIR -lcs -lct -lcomn -lintl -ltli"

  PHP_CHECK_LIBRARY(tcl, netg_errstr, [
PHP_ADD_LIBRARY(tcl,,SYBASE_CT_SHARED_LIBADD)


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] mbstring and 4.3.0

[Moriyoshi Koizumi]

Oops, why didn't I notice such a trivial thing before asking a braindead 
question... Anyway I bet the problem should be gone by my patch that was 
just commited.

Moriyoshi

"Ilia A." <[EMAIL PROTECTED]> wrote:

> On November 12, 2002 04:58 pm, Moriyoshi Koizumi wrote:
> > Hi,
> >
> > Thanks for the report.
> > Although I found a bug in the overloading code, I wonder why the mail()
> > function entry was not found on RINIT. Any insights?
> 
> It seems the mail() function is not avaliable on that system because sendmail 
> was not found on the system. The function mail() on unix systems appears to 
> be dependant on sendmail avaliablity or atleast something that would cause 
> the HAVE_SENDMAIL flag to be set.
> 
> Ilia
> 
> > Moriyoshi
> >
> > "Ilia A." <[EMAIL PROTECTED]> wrote:
> > > On November 7, 2002 10:04 am, Andrei Zmievski wrote:
> > > > At the PHP Conference in Germany several of us have discussed the
> > > > current state of mbstring and there was a proposal to not have it
> > > > enabled by default for 4.3.0 release. It seems that the extension
> > > > attempts to do "magic" stuff by overloading functions in the executor
> > > > globals and, as Thies said, that could be dangerous. Also, doesn't it
> > > > affect run-tests.php script currently?
> > >
> > > On the note of overloading done by mbstring, it appears this behavior is
> > > not entirely stable. On at least one test system (Sun OS 5.9) it causes
> > > crashes and overruns by using the test script in the test suite.
> > > Ex:
> > > sapi/cli/php -d "mbstring.func_overload=1" -r ''
> > > Unknown(0) : Fatal error - (null)() [http://www.php.net/ref.mbstring]:
> > > mbstring couldn't find function mail.
> > > Could not startup.
> > > [Tue Nov 12 21:01:33 2002]  Script:  '-'
> > > ---
> > > php4/Zend/zend_execute.h(44) : Block 0x001FB640 status:
> > > Beginning:  Overrun (magic=0x001FE7F8, expected=0x7312F8DC)
> > >   End:  Unknown
> > > ---
> > >
> > > The test script itself (ext/mbstring/tests/overload.phpt) causes a
> > > segmentation fault. Here is a back trace:
> > > #0  0x001528f8 in shutdown_memory_manager (silent=1, clean_cache=1) at
> > > php4/Zend/zend_alloc.c:461
> > > #1  0x0011d944 in php_module_shutdown () at php4/main/main.c:1219
> > > #2  0x0018d8d0 in main (argc=39, argv=0xffbffa74) at
> > > php4/sapi/cli/php_cli.c:761
> > >
> > > Ilia
> > >
> > > --
> > > PHP Development Mailing List 
> > > To unsubscribe, visit: http://www.php.net/unsub.php
> 
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
> 


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] ZEND_ADD_STRING patch

[George Schlossnagle]

Hi Andi,

The last patch I submitted was broken as well.  Following that, I had 
the bright idea to run the prospective changes through the unit-tester 
to ensure correct performance.  Here's a patch which achieves that.  It 
does not work for heredocs (i.e. they are tokenized as before, but 
behave correctly from a language perspective), but otherwise optimizes 
correctly.

Here you go:

diff -u -3 -r1.53 zend_language_scanner.l
--- Zend/zend_language_scanner.l8 Nov 2002 13:40:54 -1.53
+++ Zend/zend_language_scanner.l12 Nov 2002 22:11:31 -
@@ -37,6 +37,7 @@
%x ST_BACKQUOTE
%x ST_HEREDOC
%x ST_LOOKING_FOR_PROPERTY
+%x ST_EXPECTING_OBJECT
%x ST_LOOKING_FOR_VARNAME
%x ST_COMMENT
%x ST_ONE_LINE_COMMENT
@@ -692,6 +693,7 @@
HNUM"0x"[0-9a-fA-F]+
LABEL[a-zA-Z_\x7f-\xff][a-zA-Z0-9_\x7f-\xff]*
WHITESPACE [ \n\r\t]+
+LABEL_OR_WHITESPACE [a-zA-Z0-9_\x7f-\xff \t\n\r #'.:;,()|^&+-/*=%!~<>?@]+
TABS_AND_SPACES [ \t]*
TOKENS [;:,.\[\]()|^&+-/*=%!~$<>?@]
ENCAPSED_TOKENS [\[\]{}$]
@@ -823,13 +825,22 @@
return T_EXTENDS;
}

-"->" {
+"$"{LABEL}"->"{LABEL} {
+yy_push_state(ST_EXPECTING_OBJECT TSRMLS_CC);
+yyless(0);
+}
+
+
+"->" {
yy_push_state(ST_LOOKING_FOR_PROPERTY TSRMLS_CC);
return T_OBJECT_OPERATOR;
}

{LABEL} {
yy_pop_state(TSRMLS_C);
+if(yy_top_state(TSRMLS_C) == ST_EXPECTING_OBJECT) {
+yy_pop_state(TSRMLS_C);
+}
 zend_copy_value(zendlval, yytext, yyleng);
zendlval->value.str.len = yyleng;
zendlval->type = IS_STRING;
@@ -1265,7 +1276,7 @@
return T_INLINE_HTML;
}

-"$"{LABEL} {
+"$"{LABEL} 
{
 zend_copy_value(zendlval, (yytext+1), (yyleng-1));
zendlval->type = IS_STRING;
return T_VARIABLE;
@@ -1278,13 +1289,26 @@
return T_STRING;
}

-
-{LABEL} {
+{LABEL_OR_WHITESPACE} {
+HANDLE_NEWLINES(yytext, yyleng);
 zend_copy_value(zendlval, yytext, yyleng);
zendlval->type = IS_STRING;
return T_STRING;
}

+{LABEL} {
+zend_copy_value(zendlval, yytext, yyleng);
+zendlval->type = IS_STRING;
+return T_STRING;
+}
+
+{ESCAPED_AND_WHITESPACE} {
+HANDLE_NEWLINES(yytext, yyleng);
+zendlval->value.str.val = (char *) estrndup(yytext, yyleng);
+zendlval->value.str.len = yyleng;
+zendlval->type = IS_STRING;
+return T_ENCAPSED_AND_WHITESPACE;
+}

{WHITESPACE} {
zendlval->value.str.val = yytext; /* no copying - intentional */
@@ -1581,14 +1605,6 @@
}
}

-
-{ESCAPED_AND_WHITESPACE} {
-HANDLE_NEWLINES(yytext, yyleng);
-zendlval->value.str.val = (char *) estrndup(yytext, yyleng);
-zendlval->value.str.len = yyleng;
-zendlval->type = IS_STRING;
-return T_ENCAPSED_AND_WHITESPACE;
-}

([^'\\]|\\[^'\\])+ {
HANDLE_NEWLINES(yytext, yyleng);



--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] mbstring and 4.3.0

[Ilia A.]

On November 12, 2002 04:58 pm, Moriyoshi Koizumi wrote:
> Hi,
>
> Thanks for the report.
> Although I found a bug in the overloading code, I wonder why the mail()
> function entry was not found on RINIT. Any insights?

It seems the mail() function is not avaliable on that system because sendmail 
was not found on the system. The function mail() on unix systems appears to 
be dependant on sendmail avaliablity or atleast something that would cause 
the HAVE_SENDMAIL flag to be set.

Ilia

> Moriyoshi
>
> "Ilia A." <[EMAIL PROTECTED]> wrote:
> > On November 7, 2002 10:04 am, Andrei Zmievski wrote:
> > > At the PHP Conference in Germany several of us have discussed the
> > > current state of mbstring and there was a proposal to not have it
> > > enabled by default for 4.3.0 release. It seems that the extension
> > > attempts to do "magic" stuff by overloading functions in the executor
> > > globals and, as Thies said, that could be dangerous. Also, doesn't it
> > > affect run-tests.php script currently?
> >
> > On the note of overloading done by mbstring, it appears this behavior is
> > not entirely stable. On at least one test system (Sun OS 5.9) it causes
> > crashes and overruns by using the test script in the test suite.
> > Ex:
> > sapi/cli/php -d "mbstring.func_overload=1" -r ''
> > Unknown(0) : Fatal error - (null)() [http://www.php.net/ref.mbstring]:
> > mbstring couldn't find function mail.
> > Could not startup.
> > [Tue Nov 12 21:01:33 2002]  Script:  '-'
> > ---
> > php4/Zend/zend_execute.h(44) : Block 0x001FB640 status:
> > Beginning:  Overrun (magic=0x001FE7F8, expected=0x7312F8DC)
> >   End:  Unknown
> > ---
> >
> > The test script itself (ext/mbstring/tests/overload.phpt) causes a
> > segmentation fault. Here is a back trace:
> > #0  0x001528f8 in shutdown_memory_manager (silent=1, clean_cache=1) at
> > php4/Zend/zend_alloc.c:461
> > #1  0x0011d944 in php_module_shutdown () at php4/main/main.c:1219
> > #2  0x0018d8d0 in main (argc=39, argv=0xffbffa74) at
> > php4/sapi/cli/php_cli.c:761
> >
> > Ilia
> >
> > --
> > PHP Development Mailing List 
> > To unsubscribe, visit: http://www.php.net/unsub.php


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/snmp CREDITS php_snmp.hsnmp.c

[Harrie Hazewinkel]

--On Tuesday, November 12, 2002 10:42 PM +0100 Derick Rethans 
<[EMAIL PROTECTED]> wrote:

On Tue, 12 Nov 2002, Harrie Hazewinkel wrote:


>> These function names don't follow the PHP standards, I think we should
>> definitely come up with better names.
>
> I agree. what's wrong with snmp_get, snmp_walk, and so on?

I believe it is neccessary to have the 'v3' in the name. It makes very
clear to people that it is for snmpv3 and not any opther snmp version.

SNMPv3 is the protocol version that has security support and is known
as under SNMPv3 by many people.


But what use does it have in it's name? We don't have PGsqlV6 and
pgsqlv7_, or mysqlv3_ and mysqlv4_ (or take the gd functions).


Again I believe there is a difference between a package version number
and this protocol. I do not believe that snmp_get is an improvement over
snmpv3get for instance.

Although, I admit I have been thinking of using the used example snmp_get,
but then I need to add a version number as parameter. This would allow
as well the existing snmpget (for SNMPv1) to be combined with snmpv3get
(for SNMPv3). However, I have kept it simple for the moment and attempted
to make it as easy as possible to upgrade scripts to SNMPv3.
And on top of it, also providing a quick and well understood recognition
of it.

Also SNMPv3 is a full standard and that version number is not likely
(and hopefully) about to change.





Anyway, where would be the function name guide lines on the website.
I cannot find it and a pointer would be appreciated.


See the CODING_STANDARDS file in the root of the php4/ CVS module.


THanks, I will check it out.



Derick

--

-
--  Derick Rethans
http://derickrethans.nl/   JDI Media Solutions
--[ if you hold a unix shell to your ear, do you hear the c?
]-






Harrie

Internet Management Consulting
mailto: [EMAIL PROTECTED]   http://www.lisanza.net/

Author of MOD-SNMP, enabling SNMP management the Apache HTTP server

--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] mbstring and 4.3.0

[Moriyoshi Koizumi]

Hi,

Thanks for the report.
Although I found a bug in the overloading code, I wonder why the mail() 
function entry was not found on RINIT. Any insights?

Moriyoshi

"Ilia A." <[EMAIL PROTECTED]> wrote:

> On November 7, 2002 10:04 am, Andrei Zmievski wrote:
> > At the PHP Conference in Germany several of us have discussed the
> > current state of mbstring and there was a proposal to not have it
> > enabled by default for 4.3.0 release. It seems that the extension
> > attempts to do "magic" stuff by overloading functions in the executor
> > globals and, as Thies said, that could be dangerous. Also, doesn't it
> > affect run-tests.php script currently?
> >
> 
> On the note of overloading done by mbstring, it appears this behavior is not 
> entirely stable. On at least one test system (Sun OS 5.9) it causes crashes 
> and overruns by using the test script in the test suite.
> Ex:
> sapi/cli/php -d "mbstring.func_overload=1" -r ''
> Unknown(0) : Fatal error - (null)() [http://www.php.net/ref.mbstring]: 
> mbstring couldn't find function mail.
> Could not startup.
> [Tue Nov 12 21:01:33 2002]  Script:  '-'
> ---
> php4/Zend/zend_execute.h(44) : Block 0x001FB640 status:
> Beginning:  Overrun (magic=0x001FE7F8, expected=0x7312F8DC)
>   End:  Unknown
> ---
> 
> The test script itself (ext/mbstring/tests/overload.phpt) causes a 
> segmentation fault. Here is a back trace:
> #0  0x001528f8 in shutdown_memory_manager (silent=1, clean_cache=1) at 
> php4/Zend/zend_alloc.c:461
> #1  0x0011d944 in php_module_shutdown () at php4/main/main.c:1219
> #2  0x0018d8d0 in main (argc=39, argv=0xffbffa74) at 
> php4/sapi/cli/php_cli.c:761
> 
> Ilia
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
> 


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/snmp CREDITS php_snmp.hsnmp.c

[Derick Rethans]

On Tue, 12 Nov 2002, Harrie Hazewinkel wrote:

> >> These function names don't follow the PHP standards, I think we should
> >> definitely come up with better names.
> >
> > I agree. what's wrong with snmp_get, snmp_walk, and so on?
> 
> I believe it is neccessary to have the 'v3' in the name. It makes very clear
> to people that it is for snmpv3 and not any opther snmp version.
> 
> SNMPv3 is the protocol version that has security support and is known
> as under SNMPv3 by many people.

But what use does it have in it's name? We don't have PGsqlV6 and 
pgsqlv7_, or mysqlv3_ and mysqlv4_ (or take the gd functions). 

> 
> Anyway, where would be the function name guide lines on the website.
> I cannot find it and a pointer would be appreciated.

See the CODING_STANDARDS file in the root of the php4/ CVS module.

Derick

-- 

---
 Derick Rethans   http://derickrethans.nl/ 
 JDI Media Solutions
--[ if you hold a unix shell to your ear, do you hear the c? ]-


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/snmp CREDITS php_snmp.hsnmp.c

[Harrie Hazewinkel]

--On Monday, November 11, 2002 11:20 PM +0200 Andi Gutmans <[EMAIL PROTECTED]> 
wrote:

At 10:22 PM 11/11/2002 +0100, Derick Rethans wrote:

On Mon, 11 Nov 2002, Harrie Hazewinkel wrote:

> harrieMon Nov 11 16:09:19 2002 EDT
>
>   Modified files:
> /php4/ext/snmpCREDITS php_snmp.h snmp.c
>   Log:
>   Adding SNMPv3 support.

@@ -113,6 +121,11 @@
PHP_FE(snmp_get_quick_print, NULL)
PHP_FE(snmp_set_quick_print, NULL)
PHP_FE(snmpset, NULL)
+   PHP_FE(snmpv3get, NULL)
+   PHP_FE(snmpv3walk, NULL)
+   PHP_FE(snmpv3realwalk, NULL)
+   PHP_FALIAS(snmpv3walkoid, snmpv3realwalk, NULL)
+   PHP_FE(snmpv3set, NULL)
{NULL,NULL,NULL}

These function names don't follow the PHP standards, I think we should
definitely come up with better names.


I agree. what's wrong with snmp_get, snmp_walk, and so on?


I believe it is neccessary to have the 'v3' in the name. It makes very clear
to people that it is for snmpv3 and not any opther snmp version.

SNMPv3 is the protocol version that has security support and is known
as under SNMPv3 by many people.


Anyway, where would be the function name guide lines on the website.
I cannot find it and a pointer would be appreciated.

Cheers,


Harrie

Internet Management Consulting
mailto: [EMAIL PROTECTED]   http://www.lisanza.net/

Author of MOD-SNMP, enabling SNMP management the Apache HTTP server

--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] GD filters done patch available

[Pierre-Alain Joye]

Hello,

GD filters are done and patch against current cvs available at
http://www.pearfr.org/phpgd/filters/

Feedbacks, comments welcome

hth

pa

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] [RFC] php-cli: option to ignore php.ini

[Mike Robinson]

Good idea. This is useful. Thanks. :)

Regards
Mike Robinson


> -Original Message-
> From: Marcus Börger [mailto:marcus.boerger@;t-online.de] 
> Sent: Tuesday, November 12, 2002 4:05 PM
> To: Wez Furlong
> Cc: [EMAIL PROTECTED]
> Subject: Re: [PHP-DEV] [RFC] php-cli: option to ignore php.ini
> 
> 
> Implemented:
> 
> [marcus@zaphod php4-HEAD]$ php -r 
> 'var_dump(get_cfg_var("cfg_file_path"));var_dump(php_ini_scann
ed_files());'
> string(20) "/home/marcus/php.ini"
> bool(false)
> 
> [marcus@zaphod php4-HEAD]$ php -n -r 
> 'var_dump(get_cfg_var("cfg_file_path"));var_dump(php_ini_scann
ed_files());'
> bool(false)
> bool(false)
> 
> [marcus@zaphod php4-HEAD]$ php -c x -n -r 
> 'var_dump(get_cfg_var("cfg_file_path"));var_dump(php_ini_scann
ed_files());'
> You cannot use both -n and -c switch. Use -h for help.
> 
> marcus
> 
> At 13:31 11.11.2002, Wez Furlong wrote:
> >What are your opinions for having some option to prevent the 
> >loading/parsing of php.ini for the CLI version of PHP?
> >
> >   -n "No Ini File"  - skips parsing php.ini on startup
> >
> >At the moment, I'm using "-c DOESNOTEXIST" to achieve the 
> same result, 
> >but this is a bit hacky.
> >

> 


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] ZE2 object constructor question

[l0t3k]

im creating some classes in an extension and i have a question.
im following instructions in the OBJECTS2_HOWTO, and have managed to get the
engine to call my constructor. in the constructor i can retrieve the object
created with the create_object_handler, which means getThis() already
contains my object.
  the question is , do i still  have to explicitly set return_value, given
that getThis() is already a valid object zval ?

l0t3k



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] php-cli: option to ignore php.ini

[Marcus Börger]

Implemented:

[marcus@zaphod php4-HEAD]$ php -r 
'var_dump(get_cfg_var("cfg_file_path"));var_dump(php_ini_scanned_files());'
string(20) "/home/marcus/php.ini"
bool(false)

[marcus@zaphod php4-HEAD]$ php -n -r 
'var_dump(get_cfg_var("cfg_file_path"));var_dump(php_ini_scanned_files());'
bool(false)
bool(false)

[marcus@zaphod php4-HEAD]$ php -c x -n -r 
'var_dump(get_cfg_var("cfg_file_path"));var_dump(php_ini_scanned_files());'
You cannot use both -n and -c switch. Use -h for help.

marcus

At 13:31 11.11.2002, Wez Furlong wrote:
What are your opinions for having some option to prevent the
loading/parsing of php.ini for the CLI version of PHP?

  -n "No Ini File"  - skips parsing php.ini on startup

At the moment, I'm using "-c DOESNOTEXIST" to achieve the same result,
but this is a bit hacky.

--Wez.


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php



--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] patch fix warning in ext/gd/libgd/gd.c

[Pierre-Alain Joye]

Hello,

Fix the last warning I got in ext/gd/libg/gd.c (using -W -g3)

pa
Index: gd.c
===
RCS file: /repository/php4/ext/gd/libgd/gd.c,v
retrieving revision 1.24
diff -u -r1.24 gd.c
--- gd.c12 Nov 2002 13:12:58 -  1.24
+++ gd.c12 Nov 2002 20:56:44 -
@@ -2215,7 +2215,7 @@
int i, r, g, b, a;
FuncPtr f;
 
-   int pxlOldLeft, pxlLeft, pxlSrc;
+   int pxlOldLeft, pxlLeft=0, pxlSrc;
 
if (src->trueColor) {
f = gdImageGetTrueColorPixel;


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] CVS Account Request: adrianr

[adrian rapa]

i would like to start php manual translation in romanian

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Critical? Shutdown issue with nsapi (Bug #20274)

[Wez Furlong]

I'm a little concerned about #20274 (running out of file descriptors);
I'm not sure of the cause, but I suspect that there is some kind of
request shutdown issue with threaded servers.

The PR implies that this is a problem with iPlanet under Solaris, but it
really would be a good idea to make sure that other sapis are not
affected in the same way.

Could someone with nsapi, isapi, and any other threaded server see if
they can reproduce this issue?  The test case is essentially a script
that opens files and directories but leaves the handles open so that the
engine cleans them up at request shutdown.  Then keep on making http
requests for the script until you run out of file handles.

Once we have a better picture of the cause of the problem, we can sort
it out.

--Wez.



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] mbstring and 4.3.0

[Ilia A.]

On November 7, 2002 10:04 am, Andrei Zmievski wrote:
> At the PHP Conference in Germany several of us have discussed the
> current state of mbstring and there was a proposal to not have it
> enabled by default for 4.3.0 release. It seems that the extension
> attempts to do "magic" stuff by overloading functions in the executor
> globals and, as Thies said, that could be dangerous. Also, doesn't it
> affect run-tests.php script currently?
>

On the note of overloading done by mbstring, it appears this behavior is not 
entirely stable. On at least one test system (Sun OS 5.9) it causes crashes 
and overruns by using the test script in the test suite.
Ex:
sapi/cli/php -d "mbstring.func_overload=1" -r ''
Unknown(0) : Fatal error - (null)() [http://www.php.net/ref.mbstring]: 
mbstring couldn't find function mail.
Could not startup.
[Tue Nov 12 21:01:33 2002]  Script:  '-'
---
php4/Zend/zend_execute.h(44) : Block 0x001FB640 status:
Beginning:  Overrun (magic=0x001FE7F8, expected=0x7312F8DC)
  End:  Unknown
---

The test script itself (ext/mbstring/tests/overload.phpt) causes a 
segmentation fault. Here is a back trace:
#0  0x001528f8 in shutdown_memory_manager (silent=1, clean_cache=1) at 
php4/Zend/zend_alloc.c:461
#1  0x0011d944 in php_module_shutdown () at php4/main/main.c:1219
#2  0x0018d8d0 in main (argc=39, argv=0xffbffa74) at 
php4/sapi/cli/php_cli.c:761

Ilia

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] gd, imagefilter

[Derick Rethans]

On Tue, 12 Nov 2002, Pierre-Alain Joye wrote:

> Hello,
> 
> That's it :)
> 
> I did not find a sample privat function, now I do. For the ML archive,
> here is how to do it:
> 
> On Tue, 12 Nov 2002 17:48:08 +0100 (CET)
> Derick Rethans <[EMAIL PROTECTED]> wrote:
> 
> > typedef image_filter  {
> > void (function*)(INTERNAL_FUNCTION_PARAMETERS);
> > } image_filter;
> 
> has to be:
> typedef void (*image_filter)(INTERNAL_FUNCTION_PARAMETERS);
> 
> We do not need a bidemensional array, except if we want to add the arg
> number to avoid a useless call.
> image_filter filters[] = {_php_image_filter_none,
>   _php_image_filter_negate,
>   _php_image_filter_blur
> };

Sure, that works too :)

> ]
> the "_php_" prefix seems to be the std for privat function, confirmation?

Yes.

> 
> then the call itself:
> 
> convert_to_long_ex(FILTERTYPE);
> filtertype  = Z_LVAL_PP(FILTERTYPE);
> printf("filtertype:%i\n",filtertype);
> if (filtertype>0 && filtertype<=IMAGE_FILTER_MAX) {

If you also use the first filter entry, you can use >= 0 instead of > 0 
of course.

>   filters[filtertype](INTERNAL_FUNCTION_PARAM_PASSTHRU);
> }
> 
> and the functions to be called:
> 
> Function declaration:
> static void _php_image_filter_negate (INTERNAL_FUNCTION_PARAMETERS);
> 
> Function implementation:
> static void _php_image_filter_negate (INTERNAL_FUNCTION_PARAMETERS)
> {
>  /* do stuff */
> }
> 
> voila,
> 
> Any comments or better way to do it welcome,

Nope, this looks like that best way :)


Derick

-- 

---
 Derick Rethans   http://derickrethans.nl/ 
 JDI Media Solutions
--[ if you hold a unix shell to your ear, do you hear the c? ]-


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] gd, imagefilter

[Andrei Zmievski]

On Tue, 12 Nov 2002, Pierre-Alain Joye wrote:
> Hello,
> 
> That's it :)
> 
> I did not find a sample privat function, now I do. For the ML archive,
> here is how to do it:
> 
> On Tue, 12 Nov 2002 17:48:08 +0100 (CET)
> Derick Rethans <[EMAIL PROTECTED]> wrote:
> 
> > typedef image_filter  {
> > void (function*)(INTERNAL_FUNCTION_PARAMETERS);
> > } image_filter;
> 
> has to be:
> typedef void (*image_filter)(INTERNAL_FUNCTION_PARAMETERS);
> 
> We do not need a bidemensional array, except if we want to add the arg
> number to avoid a useless call.
> image_filter filters[] = {_php_image_filter_none,
>   _php_image_filter_negate,
>   _php_image_filter_blur
> };
> 
> the "_php_" prefix seems to be the std for privat function, confirmation
> ?

Use just "php_". "_php_" is deprecated.

-Andrei   http://www.gravitonic.com/
* Reality isn't all it's cracked up to be. *

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Proto void and return values...

[David Brown]

On Tue, Nov 12, 2002 at 02:16:41PM -0500, David Brown wrote:
| Hi everyone:
| 
| For functions prototyped as returning void, return values seem to be applied
| at random. Some functions, such as trigger_error/user_error, srand, ob_start,
| and phpinfo, use RETURN_TRUE. The vast majority of these functions just fall
| through, implicitly returning NULL to userland.

Or perhaps I'v just thought about this entirely too long. Is it possible
that the prototypes are just wrong in the documentation?

Regards,

- Dave
  [EMAIL PROTECTED]


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] gd, imagefilter

[Pierre-Alain Joye]

Hello,

That's it :)

I did not find a sample privat function, now I do. For the ML archive,
here is how to do it:

On Tue, 12 Nov 2002 17:48:08 +0100 (CET)
Derick Rethans <[EMAIL PROTECTED]> wrote:

> typedef image_filter  {
>   void (function*)(INTERNAL_FUNCTION_PARAMETERS);
> } image_filter;

has to be:
typedef void (*image_filter)(INTERNAL_FUNCTION_PARAMETERS);

We do not need a bidemensional array, except if we want to add the arg
number to avoid a useless call.
image_filter filters[] = {_php_image_filter_none,
_php_image_filter_negate,
_php_image_filter_blur
};

the "_php_" prefix seems to be the std for privat function, confirmation
?

then the call itself:

convert_to_long_ex(FILTERTYPE);
filtertype  = Z_LVAL_PP(FILTERTYPE);
printf("filtertype:%i\n",filtertype);
if (filtertype>0 && filtertype<=IMAGE_FILTER_MAX) {
filters[filtertype](INTERNAL_FUNCTION_PARAM_PASSTHRU);
}

and the functions to be called:

Function declaration:
static void _php_image_filter_negate (INTERNAL_FUNCTION_PARAMETERS);

Function implementation:
static void _php_image_filter_negate (INTERNAL_FUNCTION_PARAMETERS)
{
 /* do stuff */
}

voila,

Any comments or better way to do it welcome,

thank's Derick

pa

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Proto void and return values...

[David Brown]

Hi everyone:

In trying to do something syntatically fancy with trigger_error() today, I
came across what I believe to be an inconsistency in the way return values are
being applied throughout the PHP4 tree. Proof (hopefully) follows. :)

For functions prototyped as returning void, return values seem to be applied
at random. Some functions, such as trigger_error/user_error, srand, ob_start,
and phpinfo, use RETURN_TRUE. The vast majority of these functions just fall
through, implicitly returning NULL to userland.

IMHO, it'd add a bit of syntactic sugar to the language to allow a function
returning void to always return a NULL/unset value. Things like:

  if ($doomed)
return trigger_error('Error', E_USER_WARNING);

could take the place of longer constructs like:

  if ($doomed)
  {
trigger_error('Error', E_USER_WARNING);
return NULL;
  }

With exceptions coming, this may be a really weak point, but I figured I'd
through it out here.

A much stronger argument than the above, however, is just maintaining
consistency throughout the engine and extensions. I'm more than willing to do
the legwork on this one, if you guys are okay with it. Anyone want to dictate
an official policy? :)


Kind regards,

- Dave
  [EMAIL PROTECTED]


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: #20395 [Opn->Csd]: A handful of #ifdef's to compile under AIXusing xlC

[Derick Rethans]

On 12 Nov 2002 [EMAIL PROTECTED] wrote:

>  ID:   20395
>  Updated by:   [EMAIL PROTECTED]
>  Reported By:  [EMAIL PROTECTED]
> -Status:   Open
> +Status:   Closed
>  Bug Type: Compile Failure
>  Operating System: AIX 4.3.3ML10
>  PHP Version:  4CVS-2002-11-12
>  New Comment:
> 
> I dont think it's a bug.
> Please take this to php.dev.

Nicos, if you have little knowlegde about a specific bugreport, please 
don't assume things and add bogus comments. 

Derick

-- 

---
 Derick Rethans   http://derickrethans.nl/ 
 JDI Media Solutions   http://www.jdimedia.nl/
---


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] CVS Account Request: tofanini

[César Tegani Tofanini]

Translating the documentation

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] adding sapi_module_struct.pretty_name to $_SERVER

[Joerg Behrens]

- Original Message - 
From: "George Schlossnagle" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, November 12, 2002 6:44 PM
Subject: [PHP-DEV] [RFC] adding sapi_module_struct.pretty_name to $_SERVER


> How do people feel about adding the pretty name as $_SERVER['SAPI']?
> 

We have already php_sapi_name() ?

regards
Joerg


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] [RFC] adding sapi_module_struct.pretty_name to $_SERVER

[George Schlossnagle]

How do people feel about adding the pretty name as $_SERVER['SAPI']?


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] gd, imagefilter

[Pierre-Alain Joye]

On Tue, 12 Nov 2002 17:48:08 +0100 (CET)
Derick Rethans <[EMAIL PROTECTED]> wrote:

> On Tue, 12 Nov 2002, Pierre-Alain Joye wrote:
..
> #define FILTER_MAX2

Already done :)

> typedef image_filter  {
>   void (function*)(INTERNAL_FUNCTION_PARAMETERS);
> } image_filter;
> 
> image_filter filters[] = {
>   { image_filter_none },
>   { image_filter_negate },
>   { image_filter_blur }
> };

That s what I used

> PHP_FUNCTION(image_filter_none)
> {
>   /* do stuff */
> }
> and then have:
> 
> filters[filter_type]->function(INTERNAL_FUNCTION_PARAMETERS);

OK, there are the 2 points I missed, I ll try them tonight :-).

Thank's :)

pa

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] gd, imagefilter

[Derick Rethans]

On Tue, 12 Nov 2002, Pierre-Alain Joye wrote:

> 1. php syntax
> After a short discussion on #php, I choose to implement a generic
> function:
> bool imagefilter(resssource img, int filtertype [,arg1,argn,...]);
> where
> int filtertype are predefined constant (IMAGE_FILTER_BRIGHTNESS,
> IMAGE_FILTER_EDGEDETECT,...)
> 
> and argN depends on the used filter.
> 
> Is this syntax sounds good to you ?

It does to me.

> 
> 
> 2. The implementation
> It was clear that a generic imagefilter function is easier to use than N
> different functions (inside php). So here I went. But I did not find a
> cool way to do it. One goal of that is to make as easy as possible to
> add filters (in ext/gd/gd.c).
> 
> Currently I do:
> 
>3701 if (ZEND_NUM_ARGS()<2 || ZEND_NUM_ARGS()>5 ||
>3702 zend_get_parameters_array_ex(ZEND_NUM_ARGS(), args) ==
> FAILURE)   3703 ZEND_WRONG_PARAM_COUNT();
>3704 
>3705 FILTERTYPE  = args[1];
>3706 
>3707 convert_to_long_ex(FILTERTYPE);
>3708 filtertype  = Z_LVAL_PP(FILTERTYPE);
> 
>   
>3716 switch (filtertype) {
>3717 case IMAGE_FILTER_NEGATE:
>3718 if (ZEND_NUM_ARGS()>2) {
>3719 ZEND_WRONG_PARAM_COUNT();
>3720 }
>3721 if (gdImageNegate(im_src)==1) {
>3722 RETURN_TRUE;
>3723 }
>3724 break;
>   
> 
> I do not like the switch, I prefer to see something like an array of
> the available filters, an array of function pointers to which we pass
> the php arguments(INTERNAL_FUNCTION_PARAM_PASSTHRU). It will be easier
> to add new filters.
> 
> I try to do it but I ve failed. the problem is I need to call a function
> passing to it all php args and allowing it to return
> errors/warnings/notices to the user. This function does not have to be
> available from php.
> 
> I hope I was clear enough :-)
> 
> any comments, ideas ?

You can do something like this:

#define FILTER_NONE   0
#define FILTER_NEGATE 1
#define FILTER_BLUR   2

#define FILTER_MAX2

typedef image_filter  {
void (function*)(INTERNAL_FUNCTION_PARAMETERS);
} image_filter;

image_filter filters[] = {
{ image_filter_none },
{ image_filter_negate },
{ image_filter_blur }
};

PHP_FUNCTION(image_filter_none)
{
/* do stuff */
}


and then have:

filters[filter_type]->function(INTERNAL_FUNCTION_PARAMETERS);

which can return errors and stuff just like a normal functon can do.



regards,
Derick

PS.: This is from mind, might not work :-)

Derick
> 

-- 

---
 Derick Rethans   http://derickrethans.nl/ 
 JDI Media Solutions
--[ if you hold a unix shell to your ear, do you hear the c? ]-


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] [RFC] gd, imagefilter

[Pierre-Alain Joye]

Hello,

I m done with new filters function for the bundled gd, all seems to
compile&work well.

I m stuck with 'little' things :

1. php syntax
After a short discussion on #php, I choose to implement a generic
function:
bool imagefilter(resssource img, int filtertype [,arg1,argn,...]);
where
int filtertype are predefined constant (IMAGE_FILTER_BRIGHTNESS,
IMAGE_FILTER_EDGEDETECT,...)

and argN depends on the used filter.

Is this syntax sounds good to you ?


2. The implementation
It was clear that a generic imagefilter function is easier to use than N
different functions (inside php). So here I went. But I did not find a
cool way to do it. One goal of that is to make as easy as possible to
add filters (in ext/gd/gd.c).

Currently I do:

   3701 if (ZEND_NUM_ARGS()<2 || ZEND_NUM_ARGS()>5 ||
   3702 zend_get_parameters_array_ex(ZEND_NUM_ARGS(), args) ==
FAILURE)   3703 ZEND_WRONG_PARAM_COUNT();
   3704 
   3705 FILTERTYPE  = args[1];
   3706 
   3707 convert_to_long_ex(FILTERTYPE);
   3708 filtertype  = Z_LVAL_PP(FILTERTYPE);


   3716 switch (filtertype) {
   3717 case IMAGE_FILTER_NEGATE:
   3718 if (ZEND_NUM_ARGS()>2) {
   3719 ZEND_WRONG_PARAM_COUNT();
   3720 }
   3721 if (gdImageNegate(im_src)==1) {
   3722 RETURN_TRUE;
   3723 }
   3724 break;


I do not like the switch, I prefer to see something like an array of
the available filters, an array of function pointers to which we pass
the php arguments(INTERNAL_FUNCTION_PARAM_PASSTHRU). It will be easier
to add new filters.

I try to do it but I ve failed. the problem is I need to call a function
passing to it all php args and allowing it to return
errors/warnings/notices to the user. This function does not have to be
available from php.

I hope I was clear enough :-)

any comments, ideas ?

pa

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] try/catch/throw in php5 ?

[Jon Parise]

On Tue, Nov 12, 2002 at 02:27:49PM +0100, michel 'ziobudda' morelli wrote:

> any news about an error management in php5 ?
 
Yes, exceptions are implemented in Zend Engine 2.

-- 
Jon Parise ([EMAIL PROTECTED]) :: The PHP Project (http://www.php.net/)

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP Snaps

[Marcus Börger]

At 16:49 12.11.2002, Jon Parise wrote:

On Tue, Nov 12, 2002 at 10:22:36AM +0100, Marcus Brger wrote:

> Yes when i introduce a problem with win32 build i have to wait
> up to 4 hours until i can see the problem and try to fix it. Then
> i have to wait 4 more hours to see whther i did it correctly

That sounds sort of like a separate problem (breaking the build).

Something like a tinderbox[1] setup would be quite nice, although the
resources for it probably don't exist.

[1] http://tinderbox.mozilla.org/showbuilds.cgi?tree=SeaMonkey


That would be a dream :-)


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP Snaps

[Jon Parise]

On Tue, Nov 12, 2002 at 10:22:36AM +0100, Marcus Brger wrote:

> Yes when i introduce a problem with win32 build i have to wait
> up to 4 hours until i can see the problem and try to fix it. Then
> i have to wait 4 more hours to see whther i did it correctly
 
That sounds sort of like a separate problem (breaking the build).

Something like a tinderbox[1] setup would be quite nice, although the
resources for it probably don't exist.

[1] http://tinderbox.mozilla.org/showbuilds.cgi?tree=SeaMonkey

-- 
Jon Parise ([EMAIL PROTECTED]) :: The PHP Project (http://www.php.net/)

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: apache_hooks

[George Schlossnagle]

So I will take this course of action after 4.3.0 is branched.  Any 
objections?

George

On Sunday, November 10, 2002, at 09:40 PM, Rasmus Lerdorf wrote:

Hrm..  That's not a bad idea.  An ApacheHooks SAPI module sounds like 
the
right approach to me.

-R

On Sun, 10 Nov 2002, George Schlossnagle wrote:

While most of the code in main/ is changed minimally, the changes to
the SAPI/apache stuff are pretty extensive.  It may make sense to 
ifdef
the changes in main and create a new SAPI module for this.  I bend to
the majority though.  :)


On Sunday, November 3, 2002, at 03:49 AM, Rasmus Lerdorf wrote:

Well, since 99% of the code is the same, I'd be worried about people
remembering to merge fixes across.  At least if it is ifdef'ed people
see
the code.  But yes, I agree, that's not pretty either.

-R

On Sun, 3 Nov 2002, George Schlossnagle wrote:


Either way works for me.  Psychologically, I think it may get higher
exposure if it is #ifdef'd, but I have style reservations about 
doing
that.  How has this sort of thing been done in the past?  Is it
undesirable to fork the apache sapi into a new 'apache_hooks' sapi?
That may be easiest.

George

On Saturday, November 2, 2002, at 05:58 PM, Rasmus Lerdorf wrote:

What do you think would be the best way to make the apache_hooks 
code
more
accessible to people?  A tarball with the relevant files that
overwrites
the standard files, or perhaps it is time to #ifdef it into the 
main
branch?

-Rasmus


// George Schlossnagle
// Principal Consultant
// OmniTI, Inc  http://www.omniti.com
// (c) 240.460.5234   (e) [EMAIL PROTECTED]
// 1024D/1100A5A0  1370 F70A 9365 96C9 2F5E 56C2 B2B9 262F 1100 A5A0






--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php






--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Stepping on range()

[Derick Rethans]

On Mon, 11 Nov 2002, Jon Parise wrote:

> Attached is a patch that adds an optional "step" parameter to the
> range() function.  This allows the generation of ranges based on a
> non-one increment.  For example:
> 
> range(0, 10, 2);
> 
> ... would yield an array containing (0, 2, 4, 6, 8, 10).
> 
> The change is entirely backwards-compatible with the existing
> behavior of range().
> 
> I've also attached a test script for the new functionality.
> 
> I haven't committed the changes in the interest of getting PHP 4.3.0
> out the door, but I will if no one sees a problem.  Otherwise, I can
> hang onto this until after the release.
> 
> Documentation updates will accompany with the commit.

I like this, but I think it's a good idea to wait with committing until 
4.3.0 has been branched.

Derick
> 

-- 

---
 Derick Rethans   http://derickrethans.nl/ 
 JDI Media Solutions
--[ if you hold a unix shell to your ear, do you hear the c? ]-


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RAW POST DATA

[Andrei Zmievski]

On Tue, 12 Nov 2002, Hartmut Holzgraefe wrote:
> the current problem with HTTP_RAW_POST_DATA is just that
> i never really figured out when it should be populated
> depending on HTTP method, Content type and
> always_populate_raw_post_data, this is going to be fixed
> today

Okay.

> besides the HTTP_RAW_POST_DATA issue what i did was
> a cleanup of the HTTP content handler code in SAPI.c
> that fixes problems with PHP not comsuming content
> data although at least the apache 1.x API relies on
> it (for keepalive connections)

That needs to be tested pretty well, I imagine?

> php://input works for the apache sapi, but not with CGI
> i had no time yet to realy dig into it but i'm pretty sure
> it is a problem within the CGI sapi code and not in the
> content handler ...
> 
> i definetly want this feature in 4.3 as with plain 4.2.x
> it is impossible to handle PUT and WebDAV requests and even
> with the allow_webdav_methods patch and HTTP_RAW_POST_DATA
> extended to PUT and WebDAV specific methods you get back
> the same memory consumption problems as with file uploads
> before 4.2.0

This php://input thing is what concerns me. How much time do you need to
finish and test it? We don't want to delay RC1 too much.

-Andrei   http://www.gravitonic.com/

"Someone clearly thinks that C is a garbage collected language"
 -- Morten Welinder

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RAW POST DATA

[Hartmut Holzgraefe]

Andrei Zmievski wrote:

How much is this going to delay 4.3.0? I'm just a bit wary of changing
such an essential part of PHP interaction (with server and users) before
a big release..


the current problem with HTTP_RAW_POST_DATA is just that
i never really figured out when it should be populated
depending on HTTP method, Content type and
always_populate_raw_post_data, this is going to be fixed
today

besides the HTTP_RAW_POST_DATA issue what i did was
a cleanup of the HTTP content handler code in SAPI.c
that fixes problems with PHP not comsuming content
data although at least the apache 1.x API relies on
it (for keepalive connections)

php://input works for the apache sapi, but not with CGI
i had no time yet to realy dig into it but i'm pretty sure
it is a problem within the CGI sapi code and not in the
content handler ...

i definetly want this feature in 4.3 as with plain 4.2.x
it is impossible to handle PUT and WebDAV requests and even
with the allow_webdav_methods patch and HTTP_RAW_POST_DATA
extended to PUT and WebDAV specific methods you get back
the same memory consumption problems as with file uploads
before 4.2.0

btw: did someone work on the run-tests.php/CGI issues?
does it work again? because with CLI it is not possible to
test POST handling ...

--
Six Offene Systeme GmbH http://www.six.de/
i.A. Hartmut Holzgraefe
Email: [EMAIL PROTECTED]
Tel.:  +49-711-99091-77


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RAW POST DATA

[Jan Schneider]

Zitat von Hartmut Holzgraefe <[EMAIL PROTECTED]>:

> Jan Schneider wrote:
> > To resume: best practice is currently to use $HTTP_RAW_POST_DATA if
> > available and php://input else. And crossing fingers that either of
> them
> > works, of course. ;-)
> 
> hmyes, but it *should* be to use php://input and forget
> about $HTTP_RAW_POST_DATA alltogether hopefully ...

Since which PHP version?

Jan.

--
http://www.horde.org - The Horde Project
http://www.ammma.de - discover your knowledge
http://www.tip4all.de - Deine private Tippgemeinschaft

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RAW POST DATA

[Hartmut Holzgraefe]

Jan Schneider wrote:

To resume: best practice is currently to use $HTTP_RAW_POST_DATA if
available and php://input else. And crossing fingers that either of them
works, of course. ;-)


hmyes, but it *should* be to use php://input and forget
about $HTTP_RAW_POST_DATA alltogether hopefully ...

--
Six Offene Systeme GmbH http://www.six.de/
i.A. Hartmut Holzgraefe
Email: [EMAIL PROTECTED]
Tel.:  +49-711-99091-77


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RAW POST DATA

[Jan Schneider]

Zitat von Hartmut Holzgraefe <[EMAIL PROTECTED]>:

> Jan Schneider wrote:
> > Do you mean, this is your plan or this already works?
> 
> php://input already works with apache 1.x
> 
> it should be SAPI independant, but for some strange
> reason it doesn't work for CGI right now, and i haven't
> tested any other SAPIs yet
> 
> but with the apache 1 module i already use it for
> WebDAV PUT and it works fine for me :)

To resume: best practice is currently to use $HTTP_RAW_POST_DATA if
available and php://input else. And crossing fingers that either of them
works, of course. ;-)

Jan.

--
http://www.horde.org - The Horde Project
http://www.ammma.de - discover your knowledge
http://www.tip4all.de - Deine private Tippgemeinschaft

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] try/catch/throw in php5 ?

[michel 'ziobudda' morelli]

any news about an error management in php5 ?

tnx

-- 
--
Gli ultimi saranno i primi, ma lo sportello chiude alle 12

--
Michel  Morelli   [EMAIL PROTECTED]

ICQ UIN: 58351764   PR of Linux in Italy
http://www.ziobudda.net http://www.phpdev.it


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: CVS Account Request: toby

[nicos]

We ?

How many are you? :-)

--

M.CHAILLAN Nicolas
[EMAIL PROTECTED]
www.WorldAKT.com Hébergement de sites internets.

"Tobias Schlitt" <[EMAIL PROTECTED]> a écrit dans le message de news:
[EMAIL PROTECTED]
> We propose to write some PHP-Extensions in C.



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] PUT method support

[Hartmut Holzgraefe]

looks like this was a PHP3 only feature?

http://www.php.net/manual/sv/printwn/features.file-upload.put-method.php

--
Six Offene Systeme GmbH http://www.six.de/
i.A. Hartmut Holzgraefe
Email: [EMAIL PROTECTED]
Tel.:  +49-711-99091-77


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RAW POST DATA

[Hartmut Holzgraefe]

Jan Schneider wrote:

Do you mean, this is your plan or this already works?


php://input already works with apache 1.x

it should be SAPI independant, but for some strange
reason it doesn't work for CGI right now, and i haven't
tested any other SAPIs yet

but with the apache 1 module i already use it for
WebDAV PUT and it works fine for me :)

--
Six Offene Systeme GmbH http://www.six.de/
i.A. Hartmut Holzgraefe
Email: [EMAIL PROTECTED]
Tel.:  +49-711-99091-77


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] CVS Account Request: phpcatala

[Vicent Fornés i Oller]

I'd like to translate PHP manual into catalan.

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] updating php_error messages

[Marcus Börger]

If you do it feel free to use: http://marcus-boerger.de/docref.txt

marcus

At 14:47 12.11.2002, Tony Leake wrote:

Hi,

I have noticed in the TODO file in head one of the items is:

* Change PHP error messages, so that they point to pages or sections
in the PHP Manual.

I have a few weeks of spare evenings coming up so if anyone wants me to
I'm happy to wade through and make the changes. As far as I can see it's
just a case of changing php_error to php_error_docref and adding
NULL TSRMLS_CC as the first argument.

I don't have karma to do this so either I would need it or I could
supply patches.

Tony


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php



--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RAW POST DATA

[Kjartan Mannes]

Tuesday, November 12, 2002, 12:02:52 PM, Hartmut Holzgraefe wrote:
> But in some cases it might be necessary to deal with 'raw' POST data.
> One of these cases is input that assigns multiple values to the same
> field name. PHP post data handlers will overwrite previous values for
> that field unless the field name itself ends in the two characters
> '[]', in which case PHP treats it as an array and pushes all values
> for that name into this array. Another case are field names that do
> not map to valid PHP variable names.

The way I understand $HTTP_RAW_POST_DATA it should contain the post data
when PHP does not have a handler for the content type. Then have the
always_populate_post_data setting when turned on also set it when there
is a valid handler. (This was the 4.2 way of doing it in my experience.)

This makes logical sense as if there is a valid handler the PHP script
will have other methods to get at the data, if there isn't it can parse
it itself. If someone posts a 50MB file and isn't setting the content
type properly it is the users fault if it doesn't work or crashes.

-- 
Kjartan <[EMAIL PROTECTED]> (http://natrak.net/)
:: "Smash forehead on keyboard to continue."


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] updating php_error messages

[Tony Leake]

Hi,

I have noticed in the TODO file in head one of the items is:

* Change PHP error messages, so that they point to pages or sections
in the PHP Manual.

I have a few weeks of spare evenings coming up so if anyone wants me to 
I'm happy to wade through and make the changes. As far as I can see it's
just a case of changing php_error to php_error_docref and adding 
NULL TSRMLS_CC as the first argument.

I don't have karma to do this so either I would need it or I could
supply patches. 

Tony


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [Zend Engine 2] Errors and exceptions?

[Timm Friebe]

On Tue, 2002-11-12 at 07:54, Derick Rethans wrote:
> On 12 Nov 2002, Timm Friebe wrote:
[...]
> And that's why I would be -1 on the first one. However, the whole error 
> reporting is a pretty mess, with some extensions implementing other 
> 'philosiphies' then others. Getting this all nice and clean is another 
> point we should address in PHP 5 (just like Stig mentioned).
+1

FYI, stats for ext/*/*:

E_WARNING   2092
E_NOTICE186
E_ERROR 128
E_CORE_WARNING  2
E_CORE_ERROR1

-- 
Timm
Any sufficiently advanced bug is indistinguishable from a feature


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] DBA and Win

[Marcus Börger]

Could someone with windows please add bundled flatfile
and cdb support for ext/dba to the windows build?

thanks
marcus


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RAW POST DATA

[Jan Schneider]

Zitat von Hartmut Holzgraefe <[EMAIL PROTECTED]>:

> My approach was to provide a php://input stream instead of the
> $HTTP_RAW_POST_DATA
> variable and additional cleanup code that would swallow any unread
> content on
> request shutdown. php://input provides the same flexibility as
> $HTTP_RAW_POST_DATA,
> without being limited for post requests. It can be safely enabled by
> default
> without creating any memory problems as content data is only passed thru
> the
> PHP engine without being stored internaly.

Do you mean, this is your plan or this already works?

> The only execption is POST data that already got interpreted by a POST
> content
> type handler. As HTTP requests come in via sockets it is not possible to
> just
> rewind the stream pointer to the beginning of the content data after it
> has
> been read in and analyzed to populate the $_POST array. In this case it
> either
> has to be stored in a memory buffer just like $HTTP_RAW_POST_DATA always
> did
> or put into a temporary file.
> With in-memory storage the complete multipart/form-data handler rewrite
> would
> be rendered useless as file upload forms would still be limited by memory
> constraints. File storage on the other hand would lead to a serious
> processing
> overhead for small to average size POST requests generated by simple
> forms
> while wasting additional disk space for the majority of file uploads.
> Another alternative for multipart/form-data would be to just store the
> non-file parts in memory and read back (and MIME-encode) the uploaded
> files
> now stored in temporary disk files back on demand, so presenting the user
> a reconstruction of the original input content. This approach would
> preserve
> resources by avoiding redundant storage of data but would also require
> every
> content handler that does not just maintain a in-memory copy of input
> data
> to provide an interface for data reconstruction.

That makes the most sense to me though also sounds most complicated. ;-)
 
> None of these approaches has yet been taken, instead raw data is just
> simply
> not provided for multipart/form-data requests since 4.2, and i don't see
> a
> way to fix this for 4.3 within a reasonable time frame. Still i think my

So, I guess this answers my earlier question.

> introduction of the php://input stream is a great inporvement over the
> 'raw'
> variable, especially with file PUT and WebDAV requests in mind.
> 
> What definetly needs to be fixed is my complete missinterpretation of
> $HTTP_RAW_POST_DATA itself and the always_populate_raw_post_data setting,
> this will be done later today (but multipart/form-data POST requests will
> still be ignored no matter what always_populate... is set to due to
> memory
> preservation reasons)

If you're ready with your patches could please post a summary or table about
what data ($_POST, $HTTP_RAW_POST_DATA, php://input) is available with what
content type and what configuration? That'd be great.

Jan.

--
http://www.horde.org - The Horde Project
http://www.ammma.de - discover your knowledge
http://www.tip4all.de - Deine private Tippgemeinschaft

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [Zend Engine 2] Errors and exceptions?

[Stig S. Bakken]

On Tue, 2002-11-12 at 07:54, Derick Rethans wrote:
> On 12 Nov 2002, Timm Friebe wrote:
> 
> > On Mon, 2002-11-11 at 23:26, Stig S. Bakken wrote:
> > [...]
> > > > The problem here is that PHP's E_WARNING does not resemble an exception.
> > > > Some of the warnings raised are only of informational intent and do not
> > > > indicate the failure of a function.
> > [...]
> > > Right.  What this illustrates is that "PHP errors" as such as way too
> > > random and unstructured to be of any other use than showing error
> > > messages to developers.
> > 
> > Well, would it be wise then to either:
> > * Change informational warnings to E_NOTICE
> >   (e.g. Notice: Called ... before fetching all rows ...)
> > or
> > * Introduce E_FAIL and use it for cases when a function fails
> >   (say, fopen('/doesnotexist', 'r'))
> > 
> > In both cases, people doing string magic with $php_errormsg (if
> > ereg("not exist", $php_errormsg)) or having their own error handlers
> > consisting of constructs like
> > if (E_WARNING == $code) 
> > would see their code break.
> > 
> > As for the first suggestion, the downside is that a lot of people will
> > miss the message(s) since they've disabled E_NOTICEs.
> 
> And that's why I would be -1 on the first one. However, the whole error 
> reporting is a pretty mess, with some extensions implementing other 
> 'philosiphies' then others. Getting this all nice and clean is another 
> point we should address in PHP 5 (just like Stig mentioned).

I did not mention that here, but I would like to go through the PHP source and
introduce Unix-style (EPERM etc.) error codes in all calls to php_error().  But
that's not a topic for this mailing list.

 - Stig


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] brain damage in the gd ext [was: Re: [PHP-DEV] GD version available in script ?]

[Roman Neuhauser]

# [EMAIL PROTECTED] / 2002-11-12 12:51:37 +0100:
> On Tue, 12 Nov 2002, Derick Rethans wrote:
> 
> > On Tue, 12 Nov 2002, Roman Neuhauser wrote:
> > 
> > > Everyone: the fact that e. g. imagecreatefromgif() exists no matter
> > > what, throwing a warning if you have a wrong GD version is IMNSHO
> > > utterly dumb. The fact that it limits the number of bogus PRs
> > > doesn't justify the breakage it forces into one's code.
> > > 
> > > Could someone please fix this?
> > 
> > I thought I fixed all of this some months ago already... Will have a 
> > look.
> 
> It's all fixed, see:
> #ifdef HAVE_GD_GIF_READ
> PHP_FE(imagecreatefromgif,  NULL)
> #endif
> 
> and:
> #if HAVE_LIBGD20
> PHP_FE(imagecreatetruecolor,NULL)
> PHP_FE(imagetruecolortopalette, NULL)
> 
> So what are you referring to exactly?

Uh, 4.2.2, obviously. I missed it in NEWS in HEAD, sorry, and thanks
for fixing it!

-- 
If you cc me or take the list(s) out completely I'll most likely ignore
your message.  see http://www.eyrie.org./~eagle/faqs/questions.html

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] brain damage in the gd ext [was: Re: [PHP-DEV] GD version available in script ?]

[Marcus Börger]

You can use constant GD_BUNDLED which is either undefined, 0
or 1. Defined as means the bundeled gd version is used.

But i just implemented gd_info(). See below. Tell me please what
else do you want do see?

marcus

[marcus@zaphod php4-HEAD]$ php -r 'var_dump(gd_info());
array(10) {
  ["GD Version"]=>
  string(24) "bundled (2.0 compatible)"
  ["FreeType Support"]=>
  bool(true)
  ["FreeType Linkage"]=>
  string(13) "with freetype"
  ["T1Lib Support"]=>
  bool(false)
  ["GIF Read Support"]=>
  bool(true)
  ["GIF Create Support"]=>
  bool(false)
  ["JPG Support"]=>
  bool(true)
  ["PNG Support"]=>
  bool(true)
  ["WBMP Support"]=>
  bool(true)
  ["XBM Support"]=>
  bool(false)
}

At 12:10 12.11.2002, Roman Neuhauser wrote:

# [EMAIL PROTECTED] / 2002-09-05 20:21:15 +0200:
> Hello,
>
> Working on PEAR::Image_Transform, I realize there is no way to check
> the currently used gd version. Beside that, gd2 functions are always
> available (raise warning if wrong gd version), this forces us to make
> a first call the function and call it again :
>
> if(@ImageCreateTrueColor()){
> $new_img =ImageCreateTrueColor($new_x,$new_y);
> } else {
> $new_img =ImageCreate($new_x,$new_y);
> }
>
> Is it possible to add a constant at build time ? or is there a better
> way to do it ?
>
> thank's in advance,

Pierre,

have you received a reply to your post?

Everyone: the fact that e. g. imagecreatefromgif() exists no matter
what, throwing a warning if you have a wrong GD version is IMNSHO
utterly dumb. The fact that it limits the number of bogus PRs
doesn't justify the breakage it forces into one's code.

Could someone please fix this?

--
If you cc me or take the list(s) out completely I'll most likely ignore
your message.  see http://www.eyrie.org./~eagle/faqs/questions.html

--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php



--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] brain damage in the gd ext [was: Re: [PHP-DEV] GDversion available in script ?]

[Derick Rethans]

On Tue, 12 Nov 2002, Derick Rethans wrote:

> On Tue, 12 Nov 2002, Roman Neuhauser wrote:
> 
> > Everyone: the fact that e. g. imagecreatefromgif() exists no matter
> > what, throwing a warning if you have a wrong GD version is IMNSHO
> > utterly dumb. The fact that it limits the number of bogus PRs
> > doesn't justify the breakage it forces into one's code.
> > 
> > Could someone please fix this?
> 
> I thought I fixed all of this some months ago already... Will have a 
> look.

It's all fixed, see:
#ifdef HAVE_GD_GIF_READ
PHP_FE(imagecreatefromgif,  NULL)
#endif

and:
#if HAVE_LIBGD20
PHP_FE(imagecreatetruecolor,NULL)
PHP_FE(imagetruecolortopalette, NULL)

So what are you referring to exactly?

Derick
-- 

---
 Derick Rethans   http://derickrethans.nl/ 
 JDI Media Solutions
--[ if you hold a unix shell to your ear, do you hear the c? ]-


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php