RE: [PHP-DEV] Re: [PEAR-DEV] SOAP, XMLRPC and WSDL

I think, by the way, that this could be a good time to drop the php- prefix from new mailing list names. Do we really need to point out that it's PHP related, when the domain is lists.php.net? :) Zeev At 00:20 24/05/2002, Lukas Smith wrote: >Shane also did not like the term and I can see wher

Re: [PHP-DEV] Re: [PEAR-DEV] SOAP, XMLRPC and WSDL

At 00:08 24/05/2002, Rasmus Lerdorf wrote: >I really don't like the term Web Services. SOAP is an RPC mechanism and >has nothing to do with the web despite what M$ would like to have you >think. I think that's kind of like saying HTML has nothing to do with the web, but anyway, perception is ev

Re: [PHP-DEV] Crasher in 4.2.1 - debugging advice needed

Wild guess, but did you load an extension using dl() in the file that crashed? Zeev At 15:23 21/05/2002, Dave Brotherstone wrote: >Hi, > I've got a particular script that seg-faults when certain parts of it run >(tested with 4.1.0 and 4.2.1, both CGI and Apache module). > >I've done a back tra

Re: [PHP-DEV] zend_op_array question

EX(function_state).function is supposed to be a pointer to the op_array that you passed to execute(). Any chance the op_array is somehow deleted by mistake? Did you try looking at EX(function_state) and EX(function_state).function to understand why it's dying? At 03:02 PM 5/19/2002, Wez Furlo

Re: [PHP-DEV] Garbage Collection!

If you're adding elements to a hash you created using array_init(), and you're using the standard macros (which apparently you are) - then yes, the engine will take care of garbage collection for you. At 09:27 PM 5/17/2002, Robert Cummings wrote: >Zeev Suraski wrote: > > &

Re: [PHP-DEV] Garbage Collection!

At 09:04 PM 5/17/2002, Robert Cummings wrote: >To be honest I'm passing the return_value into my recursion Not sure what you mean by that - return_value is handled by the engine as soon as you return from your function implementation, if that's what you're asking. If you're using it internally

Re: [PHP-DEV] Garbage Collection!

At 08:53 PM 5/17/2002, Robert Cummings wrote: >Let's say I do: > > zval *newVar; > MAKE_STD_ZVAL( newVar ); > ZEND_SET_SYMBOL( &EG(symbol_table), "varKey", newVar ); > >and then I do: > > MAKE_STD_ZVAL( newVar ); > ZEND_SET_SYMBOL( &EG(symbol_table), "varKey", newVar ); > >This

Re: [PHP-DEV] Command line compilation under win32

php4' directory will be used rem 3) "cvsup", which is like "cvs", except the CVS repository remwill be updated first rem rem Author: Zeev Suraski <[EMAIL PROTECTED]> rem Defaults set configuration=Release_TS set build_type=/rebuild if "%1" == "

Re: [PHP-DEV] Safe Mode

At 04:38 PM 5/13/2002, Jason T. Greene wrote: > > I do, for two simple reasons: > > - Misperception about what it's supposed to do - it does NOT secure your > > environment, people expect it to. That's a 'marketing' issue, but we > > should realize that these kinds of issues are at least as imp

Re: [PHP-DEV] Probably a simple answer...

zval strings must be NULL terminated, even if they contain binary data. The str.val.len property represents the length of the string w/o the terminating NULL. Zeev At 16:39 14/05/2002, Robert Cummings wrote: >brad lafountain wrote: > > > > Well i do believe that the zval string SHOULD be null

Re: [PHP-DEV] Profiling PHP

At 23:59 13/05/2002, Stig S. Bakken wrote: >Seeing that the single most time-consuming function is zend_parse, it >would be interesting to see where the bottleneck moves when using >ZendAccelerator or another caching product. Did you try that setup with >NuMega's profiler? It still stays in the

Re: [PHP-DEV] Profiling PHP

exact numbers, but the functions are more or less the same). Zeev At 18:43 13/05/2002, Rasmus Lerdorf wrote: >I did specify the profiler on line 4 of the message. And it is a pretty >good one actually. > >On Mon, 13 May 2002, Zeev Suraski wrote: > > > We already tried our be

Re: [PHP-DEV] Profiling PHP

We already tried our best to optimize most of the functions that show up in profiling. Not surprisingly, they are mostly the infrastructure functions... What profiler are you using? If it's under Linux, chances are it's *extremely* inaccurate. Profiling under Linux is horrible. Zeev At 17:

Re: [PHP-DEV] Safe Mode

At 11:42 13/05/2002, veins wrote: > > He has a point in the sense that it's trivially easy to starve a PHP based > > web server from within, safe mode enabled or not. What you describe as >the > > automated way in which the web server will overcome this attack is not > > realistic - pretty quickl

Re: [PHP-DEV] Safe Mode

Jason, He has a point in the sense that it's trivially easy to starve a PHP based web server from within, safe mode enabled or not. What you describe as the automated way in which the web server will overcome this attack is not realistic - pretty quickly, the web server would hit the maximum

Re: [PHP-DEV] Re: Bug #17168: error_log can be used to bypass safe_mode

We can check it at the ini handler level. We can either forbid modifying error_log from userspace (denying PHP_INI_USER), deny it only in safe mode, or even apply the safe mode restriction at that level. At 00:25 13/05/2002, Rasmus Lerdorf wrote: >Not quite sure how to fix this one. It's not

Re: [PHP-DEV] Segfault in current HEAD

At 21:33 12/05/2002, Sebastian Bergmann wrote: >Zeev Suraski wrote: > > This trace isn't meaningful... > > I know. How would I produce a more useful one? It's probably not possible - the best thing to do is to try to cut down the script to the smallest one that sti

Re: [PHP-DEV] Segfault in current HEAD

This trace isn't meaningful... At 20:36 12/05/2002, Sebastian Bergmann wrote: > Can't tell how to reproduce this, it occurs when working with Harald's > form validation system, which is built on top of PEAR::XML_Transformer: > >NTDLL! 778cb892() >NTDLL! 778cb733() >shutdown_memory_manager(int

Fwd: Re: [PHP-DEV] Re: Any idea why we have two html_puts()'s?

I messed up on the test, I left output buffering enabled for tests 2 and 3. So you can see that using output buffering on top of the global output buffering (whether specialized or not) slows you down by about 30%. However, to be fair, the numbers w/o global output buffering enabled: Speciali

Re: [PHP-DEV] Re: Any idea why we have two html_puts()'s?

At 19:00 12/05/2002, Sascha Schumann wrote: > > Again, I fail to understand the logic behind it. I'll change the space > > handling code to your method (which is indeed nicer); Why on earth would > > we need to have a stupid HTML printout function as a function pointer? > > If you would also

Re: [PHP-DEV] Re: Any idea why we have two html_puts()'s?

At 18:34 12/05/2002, Sascha Schumann wrote: > I favor php_html_puts also due to maintability reasons. > Please consider this part of code from zend_html_puts: > > && !(((ptr+1)>=end) || (*(ptr+1)==' ')) /* next is not a space */ > && !((ptr==s) || (*(ptr-1)==' ')))

Re: [PHP-DEV] Re: Any idea why we have two html_puts()'s?

I'd *really* like to avoid having two copies of the same code, though. Please remove the duplicated implementation... Zeev At 18:24 12/05/2002, Sascha Schumann wrote: > > What I'm pointing out is that there are no 'inherent flaws' in the 'dog > > slow' implementation that we already had for a

Re: [PHP-DEV] Re: Any idea why we have two html_puts()'s?

At 18:24 12/05/2002, Sascha Schumann wrote: > - it is buffering as you already noted without having to rely > on the huge output-buffering infrastructure. I have not > benchmarked it, but I do assume that it is noticably slower > than php_html_puts. > > - it is faster du

Re: [PHP-DEV] Re: Any idea why we have two html_puts()'s?

At 17:58 12/05/2002, Sascha Schumann wrote: > > What inherent flaws? So far, the only difference between them that I could > > spot was that php_html_puts() was buggy, and did not convert series of > > spaces into  's. Otherwise, the only difference was the use of > > buffering. I may have miss

Re: [PHP-DEV] Re: Any idea why we have two html_puts()'s?

At 17:43 12/05/2002, Sascha Schumann wrote: > I've just noticed that you have kicked out the premier > implementation of the same functionality in favor of the dog > slow old one. I almost missed those idyllic descriptions :) > Note that relying on output buffering alone is infer

Re: [PHP-DEV] Re: Any idea why we have two html_puts()'s?

Hmm, then it could be fixed, but we shouldn't introduce a new implementation. Assuming you refer to the large number of output calls, they can be saved using output buffering - implementing localized buffering in every place is not a good way to go by. I'm not sure output buffering was already

Re: [PHP-DEV] Safe Mode

At 20:17 11/05/2002, Rasmus Lerdorf wrote: > > Ideally every ISP would use it and each virtual host would have such a > > directory. In reality I've set to see a SINGLE ISP that has used that > option. > > In fact I didn't know about it myself until you told me about on IRC. > >Well, it is well d

[PHP-DEV] Any idea why we have two html_puts()'s?

We currently have two html_puts()'s - the old zend_html_puts(), and a relatively new php_html_puts(). Was there any good reason for adding php_html_puts()? It duplicates the same logic of both zend_html_putc() and zend_html_puts(). Zeev -- PHP Development Mailing List

Re: [PHP-DEV] RFI: Request for Interfaces

At 12:12 07/05/2002, Wez Furlong wrote: >On 04/05/02, "Zeev Suraski" <[EMAIL PROTECTED]> wrote: > > One thing that I'm personally don't really understand, is what kind of > > support this needs from the infrastructure. As far as I can tell, we > coul

Re: [PHP-DEV] RFI: Request for Interfaces

At 03:04 04/05/2002, Zeev Suraski wrote: >One thing that I'm personally don't really understand reread entire paragraph after rewriting parts of it -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFI: Request for Interfaces

One thing that I'm personally don't really understand, is what kind of support this needs from the infrastructure. As far as I can tell, we could define php_database_interface (example), with the necessary callbacks, and use it directly in all pieces of code that require/support it. I don't e

Re: [PHP-DEV] config.w32.h...registry configuration

At 17:24 03/05/2002, Jim Winstead wrote: >Zeev Suraski <[EMAIL PROTECTED]> wrote: > > We could add it. I just hope people wouldn't start demanding control > > structures in there to start selectively loading other files... > >let's just hope that by the

Re: [PHP-DEV] resource problem, advice wanted

At 12:02 01/05/2002, Stig Venaas wrote: >This is a bit involved, I'll try to explain. I'm trying to fix a >problem in the LDAP extension, but not sure how best to do it. > >The issue is that code like > >$e = ldap_first_entry($ds, ldap_read($ds,$dn,"objectClass=*")); >$a = ldap_get_attributes($ds,

Re: [PHP-DEV] PHP 4.3 charter and release plan

At 08:17 03/05/2002, Stig S. Bakken wrote: >Does this organization of the 4.3 release sound reasonable? Yep. Zeev -- PHP Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] config.w32.h...registry configuration

At 07:51 03/05/2002, Stig S. Bakken wrote: >Edin and I were discussing ini files on IRC last night and the same idea >came up. With the exact same syntax too, actually. This is divine >proof that the include_ini is good and must be implemented. :-) > >Seriously, being able to include other ini f

RE: [PHP-DEV] A better strlcat()

To make it clear, this *WAS* a joke :) At 04:36 03/05/2002, Zeev Suraski wrote: >At 03:58 03/05/2002, Preston L. Bannister wrote: >>Heh - there's a question :). >> >>Looking at the two implementations, which do you think you better >>understand (with complete ce

Re: [PHP-DEV] config.w32.h...registry configuration

> > php-apache-4.2.1.ini > php-apache.ini > php.ini > > ? > > This way it's even more less pain to have different versions > installed. > > - Markus > >On Fri, May 03, 2002 at 06:54:41AM +0200, Stig S. Bakken wrote : &g

RE: [PHP-DEV] A better strlcat()

At 03:58 03/05/2002, Preston L. Bannister wrote: >Heh - there's a question :). > >Looking at the two implementations, which do you think you better >understand (with complete certainty), and which would you be willing >to (say) bet your life on? Are you implying that cryptic pointer arithmetic is

Re: [PHP-DEV] config.w32.h...registry configuration

On Thu, 2 May 2002, Shane Caraveo wrote: > #4 is realy needed for systems running virtual servers under IIS. While > you can configure ini in the registry, it's a pain, especially if you > want to give users access to edit their own ini file, or you want > different extensions loaded for diff

Re: [PHP-DEV] Re: Xdebug extension availability

Because it's not efficient enough... ZE2 is going to have these features built-in in a way that would have no performance impact. Zeev At 14:38 02/05/2002, Sebastian Bergmann wrote: >[EMAIL PROTECTED] wrote: > > Yeah, I know... but it doesn't belong in ext/ because it's a > > Zend_extension. PE

Re: [PHP-DEV] config.w32.h...registry configuration

At 15:09 02/05/2002, [EMAIL PROTECTED] wrote: > > Ok then, perhaps we should have an .ini setting for it? :) > >So you want to add an .ini setting where the .ini file could be found? >That just doesn't make sense to me :) That was a joke.. > > The only two options I see, in that case are: > > >

Re: [PHP-DEV] config.w32.h...registry configuration

We're not necessarily talking about Win32... Zeev At 14:02 02/05/2002, Dan Hardiker wrote: >At the risk of getting toasted out of the water... do any serious hosters >use a Win32 enviroment to host on? (who would utilise this way of setting >different settings for different clients) > >Are there

Re: [PHP-DEV] config.w32.h...registry configuration

At 14:00 02/05/2002, [EMAIL PROTECTED] wrote: >On Thu, 2 May 2002, Zeev Suraski wrote: > > > At 13:36 02/05/2002, [EMAIL PROTECTED] wrote: > > >Some hosters use this feature to have different settigns for different > > >customers... > > > > Do you kn

Re: [PHP-DEV] config.w32.h...registry configuration

At 13:36 02/05/2002, [EMAIL PROTECTED] wrote: >Some hosters use this feature to have different settigns for different >customers... Do you know this for a fact, or is this an estimate? Zeev -- PHP Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.p

Re: [PHP-DEV] config.w32.h...registry configuration

x27;s been pointed out that the CWD lookup can be a potential security risk, because it allows people to override php.ini in some shared hosting environment setups, so it's another reason to replace it with the path lookup) Zeev At 23:17 01/05/2002, Zeev Suraski wrote: >At 23:11 01/0

Re: [PHP-DEV] config.w32.h...registry configuration

At 23:11 01/05/2002, Shane Caraveo wrote: >That would only solve that particular situation, what about multiple >installations of the same version, or seperate configurations for the same >installation? We can have PHP look for php.ini in the directory where php.exe is located. This would all

Re: [PHP-DEV]

At 18:44 27/04/2002, Stig S. Bakken wrote: >On Sat, 2002-04-27 at 03:30, Zeev Suraski wrote: > > At 03:18 27/04/2002, Rasmus Lerdorf wrote: > > >It looks like we can. I was assuming the SGML characteristics for XML and > > >it looks like I was wrong. A '>'

Re: [PHP-DEV] Discourage use of short tags

At 04:41 27/04/2002, Yasuo Ohgaki wrote: > > > Use of short tags is strongly discouraged. It is disabled by default > from PHP 4.3.0. Short tags are not only non-portable, but also non-XML > compliant. > > I object. I don't see an overwhelming reason to disable short tags by default,

Re: [PHP-DEV]

a scaled down and easier to learn/work with version of >SGML. > >Correct me if I'm wrong > >--Andrew > >On Friday 26 April 2002 07:30 pm, Zeev Suraski wrote: > > At 03:18 27/04/2002, Rasmus Lerdorf wrote: > > >It looks like we can. I was assuming the SGML cha

Re: [PHP-DEV]

At 03:18 27/04/2002, Rasmus Lerdorf wrote: >It looks like we can. I was assuming the SGML characteristics for XML and >it looks like I was wrong. A '>' is ok inside the tags. Ok, so that's actually useful. But it sounds odd - XML is not SGML compliant? Zeev -- PHP Development Mailing List

Re: [PHP-DEV]

At 20:52 26/04/2002, Rasmus Lerdorf wrote: > > $bar) > > ... > > ?> > > > > Is this valid XML? > >No, this is technically invalid XML. You would have to write it as: > > But sheez... That's just way too ugly, you can work around it and there >are other examples out there of people breaking thi

Re: [PHP-DEV]

At 20:32 26/04/2002, Gabriel Ricard wrote: >Why are short tags ( and <% %>) such a bad thing? <% %> are bad because they're not supported on most setups. are not good enough because they're not supported on all setups, even though they're supported on most. As to why they're not supported on a

Re: [PHP-DEV]

At 21:07 26/04/2002, Sterling Hughes wrote: >The whole point of the XML documents. When short tags are disabled, commands such as <% echo >'HELLO'; %> don't work. If you allow syntax, it is not valid >XML, which negates the point of having $bar) ... ?> Is this valid XML? [I'm not taking sid

Re: [PHP-DEV] Re: Bug #16838 Updated: PHP short_open_tags and

Comparing notice for undefined variables and short tags makes no sense in my opinion. There's absolutely nothing wrong with using short tags if you have short tags turned on, and you're using for code that you don't intend to be distributed for reuse. That is not the case with using undefined

Re: [PHP-DEV] PHP 4.2.0 Release Announcement

At 05:30 23/04/2002, Brian Foddy wrote: >Experimental kinda implies that its at least usuable and might be >fun to play with. Not recommending for production is a long ways >from saying ohh, I guess it will coredump on startup... Experimental means experimental, and that it may very well crash o

Re: [PHP-DEV] Major Bug in multiple MySQL Connections?

If you're tying two pieces of software together (which is apparently what he's doing), the reuse of the link can indeed be annoying, and it may make sense to have multiple links with the same credentials. Not a common case, but it's possible. Zeev At 15:42 22/04/2002, Rasmus Lerdorf wrote: >

Re: [PHP-DEV] [PATCH] --enable-inline-optimization => --disable-inline-optimization

How much time and memory did compiling zend_execute.c take? Zeev At 10:08 21/04/2002, Yasuo Ohgaki wrote: >Hi all, > >It seems we are better have --enable-inline-optimization option >after all. > >Andi told some "inline" directive has removed to make zend_execute.c >work well with -O2. (I don't

Re: [PHP-DEV] Re: Bug #16687 Updated: Constants not being interpreted in "variable variables"

#x27;t want to screw up the implementation and performance of _GET for > BC. > > If you need BC you should stick to the old ones that is why they have been > > left behind. > > > > Andi > > > > At 15:32 19/04/2002 -0500, Lux wrote: > > >On Fri, 2002-0

Re: [PHP-DEV] Re: Bug #16687 Updated: Constants not being interpreted in "variable variables"

At 21:18 19/04/2002, Lux wrote: >One other quick question: Can you make references to the superglobals, >then call these as "variable variables"? Yes. Can you explain when you need to use these global structures indirectly? Zeev -- PHP Development Mailing List To unsub

[PHP-DEV] Re: Bug #16687 Updated: Constants not being interpreted in "variable variables"

At 21:08 19/04/2002, Derick Rethans wrote: >on 19 apr 2002 [EMAIL PROTECTED] wrote: > > > id: 16687 > > updated by: [EMAIL PROTECTED] > > reported by: [EMAIL PROTECTED] > > status: bogus > > bug type: scripting engine problem > > operating system: r

Re: [PHP-DEV] Constant Classes

; was that it, well, was >constant. Wouldn't it make more sense to auto-clone objects when they are >accessed through a constant > >Medvitz > > >Zeev Suraski wrote: > > > It'll be the same object. > > > > At 17:33 14/04/2002, medvitz wrote: >

Re: [PHP-DEV] Constant Classes

It'll be the same object. At 17:33 14/04/2002, medvitz wrote: >This may have been addressed already but: > >If I have the following code: > >class Beer >{ >... >} > >$a = new Beer(); > >define('BaseBeer', $a); > >$b = BaseBeer; > > >Will $a & $b be the same object or will $b be a copy. (Un

Re: [PHP-DEV] object refrences (POSSIBLE MAJOR BUG)

At 01:45 12/04/2002, brad lafountain wrote: >I really don't think that is the problem... > >Im pretty sure i know exactly whats going on.. if you look at the zend_execute >it automatically adds a is_ref = 1; and a ref_count++; for all method calls( >the comment next to this line says /* for $this

Re: [PHP-DEV] Let's fork GD!

Sounds like a good idea. At 01:26 12/04/2002, Rasmus Lerdorf wrote: >outstanding patches and default to building from the bundled library much >like we do with MySQL. I think GD is a popular enough extension for PHP >that it would be extremely cool to have decent truecolor GD2 support >available

Re: [PHP-DEV] Re: aggergate vs MI

You described my thoughts *perfectly* - thanks :) Zeev At 16:26 09/04/2002, Lauri Liinat wrote: >hi all, > > > I'm personally in favour of having MI in PHP, with the serious alternative > > being interfaces. I have failed to understand what interfaces would mean > > in a language such as PHP, t

Re: [PHP-DEV] Re: aggergate vs MI

At 14:03 09/04/2002, Wez Furlong wrote: >On 09/04/02, "Zeev Suraski" <[EMAIL PROTECTED]> wrote: > > COM's a hack, though. It really is. > > What they did in ATL basically > > does a fair amount of magic to give you the ability to inherit code wit

RE: [PHP-DEV] Re: aggergate vs MI

At 13:12 09/04/2002, Pierre-Alain Joye wrote: > > I have failed to understand what interfaces would mean > > in a language such as PHP, though, while I can see the clear hands-on use > > for MI. Can you explain how you envision interfaces as useful constructs > > in PHP, and their advantages ove

Re: [PHP-DEV] aggregate() und overload()

At 12:38 09/04/2002, Kristian Koehntopp wrote: >On Tue, Apr 09, 2002 at 12:23:57PM +0300, Zeev Suraski wrote: > > For the record, the advantages and disadvantages of variable name > > constructors were clear from day one, > >Nonetheless they were seriously broken in PHP 3,

Re: [PHP-DEV] Re: aggergate vs MI

nd why go to all this trouble? So that your code can work with code >written by third parties that have no knowledge of your code, nor yours >of their code. > >So it's really "just" interfaces then, but more flexible because you >are not limited to just implementing interfaces

Re: [PHP-DEV] Re: aggregate() und overload()

For the record, the advantages and disadvantages of variable name constructors were clear from day one, this issue has been hashed way before PHP even had OO. Your opinion was that it'd be better to have a common name, and eventually the discussion about the revised OO model suggested that it

Re: [PHP-DEV] Re: aggergate vs MI

ng about the classes it's going to work with, it doesn't make too much sense... or does it? In your example, I understand what it does, but I don't understand what's the advantage over MI in this case. At 11:53 09/04/2002, Kristian Koehntopp wrote: >On Tue, Apr 09, 2002 at

Re: [PHP-DEV] Re: aggergate vs MI

At 01:51 09/04/2002, brad lafountain wrote: >But do you see my point that having ONLY aggregate means that in 90% of the >case where people will use it its probally a bad idea. They are only using it >becuase of the lack of MI. How does aggregation solve overwriting methods. Yes, I see the point.

Re: [PHP-DEV] Re: aggergate vs MI

At 00:55 09/04/2002, brad lafountain wrote: > Well i would have totally agreed with you yesterday.. but i have convinced >myself that there is use for aggregation. Me personally i would never use it. >But i can see somepeople using it. It doesn't mean it's a good idea to add it. I used both, an

Re: [PHP-DEV] Re: aggergate vs MI

At 00:44 09/04/2002, brad lafountain wrote: >If aggregation is included then i see it is absoulty necessary to include MI >too. In my opinion, only one of them (at most) has room in PHP. Having both is messy. My personal preference is MI, which is why I prefer tagging aggregation as experimen

Re: [PHP-DEV] Re: aggergate vs MI

Having both makes very little sense. Compile-time vs. run-time in PHP doesn't make any real difference as far as functionality goes, because the stages are linked together immediately. I don't think MI will make it into PHP, now that aggregation was introduced... At 18:59 08/04/2002, brad lafo

Re: [PHP-DEV] aggergate vs MI

There wasn't any decision made, but someone went forward and implemented aggregation :) At 01:59 AM 4/6/2002, brad lafountain wrote: >I keep on hearing that "we" are totally against MI but "we" want the aggergate >function. > > Can someone PLEASE explain the reasoning behind such a decision? >

Re: [PHP-DEV] specifying compression level to zlib.output_compression

Ones that have PHPAPI in front of them :) Zeev At 02:25 PM 4/5/2002, Derick Rethans wrote: >On Fri, 5 Apr 2002, Zeev Suraski wrote: > > > Any particular reason not to just change the signature of > > php_deflate_string()? Do you think anything else uses this functio

Re: [PHP-DEV] __CLASS__ patch - returns called class

This should really be implemented 100% in compile time, if you touch zend_execute.c, BUZZ :) Anyway, incidentally, Jani implemented this very patch a few days ago. We'll probably import it within a couple of days after we verify that it doesn't cause any gotcha's... Zeev At 12:34 PM 4/5/200

Re: [PHP-DEV] Re: aggregate() und overload()

I think that the key problems are: (a) It's unclear if the current behavior is the 'right thing' to do, as demonstrated by Kristian and yourself... (b) I personally think that it pretty much set the final decision on MI (as in, there won't be MI), because having both aggregation and MI in a lan

Re: [PHP-DEV] specifying compression level to zlib.output_compression

Any particular reason not to just change the signature of php_deflate_string()? Do you think anything else uses this function? I doubt it, especially considering its not marked as an API function... Otherwise, it sounds good... Zeev At 11:58 AM 4/5/2002, Stig S. Bakken wrote: >Hi, > >I need

Re: [PHP-DEV] Re: aggregate() und overload()

I agree with Yasuo - these functions put a de-facto functionality standard in a highly debated topic that has not yet reached consensus - the least we could do is point out to people that it may very well change in the future... Zeev At 04:40 AM 4/5/2002, Yasuo Ohgaki wrote: >--disable-experim

Re: [PHP-DEV] aggregate() und overload()

At 10:05 AM 4/5/2002, Stig S. Bakken wrote: > > Recommendation: > > > > If overload() indeed supports variably named callback functions > > such as __get_x(), support for this should be removed in order > > to avoid a number of possible inconsistencies and namespace > > pollution. > >I don't parti

RE: [PHP-DEV] W32api functions

At 06:16 PM 4/3/2002, [EMAIL PROTECTED] wrote: >And w32api is in PECL CVS btw. What exactly does this mean, considering it's also in php4/ext/w32api? Zeev -- PHP Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Mysql Patch for Multi-User Safety

Problems I could spot: - You use (*z_user)->value.str.val without making sure that z_user is of type string. You must have convert_to_string_ex(z_user) first (line 159 of the patch) - You don't allocate room for the NULL terminator in tmp_filename (line 188 of the patch) Do you know where it

Re: [PHP-DEV] W32api functions

Yes and yes... At 01:24 AM 4/3/2002, Ilia A. wrote: >Hello, > >Are the W32api functions in the CVS will make it into the upcoming 4.2 >release and if so will they be a part of the standard binaries distributed >for windows? > >Thanks, > >Ilia > >-- >PHP Development Mailing List

Re: [PHP-DEV] error handler callback gets silenced errors

Don't you think it's better to allow the user to decide inside the handler whether he wants to silence this error? It makes custom error loggers more powerful, even if error_reporting is set to 0 in the php.ini file. I think that if we are to pay attention to EG(error_reporting) before we call

Re: [PHP-DEV] thread safety for binding issues

At 20:59 30/03/2002, Markus Fischer wrote: > Yes, exactly. Ok, in that case, by default this won't work 'very nicely' with PHP (because it's not very standard), but you should be able to get it to work relatively easily. The problem: All of PHP's resources (globals, memory management, res

Re: [PHP-DEV] thread safety for binding issues

Markus - is that what you're talking about..? Zeev At 20:37 30/03/2002, Shane Caraveo wrote: >My understanding from Markus' original email was that the library he is >using calls back into php on a different thread than that which he called >it with. > >Shane -- PHP Development Mailing List

Re: [PHP-DEV] thread safety for binding issues

the problem is just that I mixed up two different > things (thread-safety vs. multi-threaded). Err .. any idea > if/when PHP itself will get MTed ? :) > > - Markus > >On Sat, Mar 30, 2002 at 09:14:56AM +0200, Zeev Suraski wrote : > > It should work, it's us

Re: [PHP-DEV] thread safety for binding issues

It should work, it's using exactly the same thread safe code as the one under Windows... Zeev At 14:14 29/03/2002, Markus Fischer wrote: > Hi, > > how much thread-safe is PHP on linux when compiled with > --enable-experimental-zts ? When I a set up a callback > handler for a 3rd

Re: [PHP-DEV] Re: Infinite Loop / Segfault in ob_*()

At 04:54 PM 3/24/2002, Sebastian Bergmann wrote: > In this callback, I use the ext/xml functions to parse this XML data. > Now when, for instance, a parse error occurs, I need to emit an > appropriate error messsage, hence I need to stop the output buffering > and output something. And, at

Re: [PHP-DEV] Question concerning zend_mem_header

At 02:08 PM 3/23/2002, Stefan Esser wrote: >Hi, > >currently all memory allocated with emalloc has a >zend_mem_header infront of it. This header contains >the backward and forward pointer and the size of this >block. My question is: is there any need for this >linked list on a production system? I

Re: [PHP-DEV] Preview version of Zend Engine 2 powered PHP

Yasuo, Please don't reopen this discussion. Please, pretty please. Zeev At 01:35 PM 3/23/2002, Yasuo Ohgaki wrote: >Andi Gutmans wrote: >>At 11:48 23/03/2002 +0100, Sebastian Bergmann wrote: >>> Why not make two tarballs when PHP 4.2.0 gets released? One with the >>> Zend Engine 1, and the

Re: [PHP-DEV] php generator

Adobe GoLive 6.0 has PHP generation built into it. I've never actually used it, but it's supposed to be a pretty good start. If you're looking for a more code-level IDE, then you can go with Daniel's recommendations... Zeev At 10:34 AM 3/20/2002, W McCloud wrote: >We are trying to find a php

Re: [PHP-DEV] OT? buffer overflow attacks

At 10:50 AM 3/20/2002, Stefan Esser wrote: >PS: anything written in this mail is my personal opinion and I do not >speak for the rest of the php developers. You spoke for me, alright :) Zeev -- PHP Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /main memory_streams.c

I made two changes - one was whitespace only, the other one was the initialization of ms... Zeev At 21:47 19/03/2002, Marcus Boerger wrote: >At 20:16 19.03.2002, you wrote: >zeevTue Mar 19 14:16:21 2002 EDT > > Modified files: > /php4/main memory_streams.c > Log: > Poss

RE: [PHP-DEV] RFC: Small changes in CODING_STANDARD

At 19:35 18/03/2002, Chris Newbill wrote: >Except is should be side-effect, not side of effect. :) Oh yeah:) -- PHP Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Cleaning up streams when connection aborted

At 18:51 18/03/2002, Wez Furlong wrote: > > Connection handling varies across different web servers. If you're really > > paranoid, you can use > > > > HANDLE_BLOCK_INTERRUPTIONS() > > and > > HANDLE_UNBLOCK_INTERRUPTIONS() > >Should I bother with this in streams? Well, I wouldn't :) Zeev --

Re: [PHP-DEV] Cleaning up streams when connection aborted

At 14:22 18/03/2002, Wez Furlong wrote: >I should have explained what I was thinking a little better: > >stream = php_stream_open_wrapper(...) >// what if the connection aborts here? >ZEND_REGISTER_RESOURCE(...) Well, no matter how you do it, it's not going to be atomic. If you do it inside ph

Re: [PHP-DEV] Cleaning up streams when connection aborted

At 13:04 18/03/2002, Wez Furlong wrote: >I've noticed a couple of places in the code where ZEND_REGISTER_RESOURCE >is used to remember to cleanup streams, and then deletes the list entry >when it has completed what it was doing. > >It's a nice idea, but it doesn't feel safe to me (probably because

<    1   2   3   4   5   6   7   8   9   10   >