Re: [PHP-DEV] RFC: Traits for PHP
Marcus, Jochem,
Although I agree with the general idea, I feel strongly against
possesses, mainly because for a non-native english speaker it's a pita
to write and will (and I'm sure of this) *very* often be misspelled
(leading to general annoyances while debugging). I can't give any better
fitting keywords for it though, but possesses is definitly not the best
choice imo.
- Tul
Marcus Boerger wrote:
Hello Jochem,
good arguments. And good ideas. I'd favor 'posesses' then.
marcus
Tuesday, February 19, 2008, 9:54:09 PM, you wrote:
firstly, I'd like to reiterate the general sentiment
that Stefans RFC is blinding! (that's a good thing in this context ;-)
Marcus Boerger schreef:
Hello Lars,
we could even go for include here if we wanted to avoid use as much as
adding a new keyword. Personally I don't mind using keywords for different
stuff as long as it cannot conflict. That is in this case true for both
include and use.
how about 'possesses' or 'exhibits' - both these words are closer to the
natural language usage of 'trait' with regard to a subject.
John exhibits a trait
Jack possesses a trait
a person coming accross 'use' or 'include' in the context of
trait attribution may either make assumptions or become confused as to
possible changes/additions to the use and/or include functionality, a
new keyword that aptly describes the intention will more likely force
users to actually find out what it means.
an another alternative might be 'applies' - which doesn't fit the
natural language usage of 'trait' but does succintly describe what is happening.
just a thought.
marcus
Tuesday, February 19, 2008, 9:31:29 PM, you wrote:
Hi Stefan,
Am Montag, den 18.02.2008, 20:27 +0100 schrieb [EMAIL PROTECTED]:
[...]
class ezcReflectionMethod extends ReflectionMethod {
use ezcReflectionReturnInfo;
/* ... */
}
I'm not sure if the use-keyword is a good idea as namespaces are already
used. If we use use for traits, maybe going back to import for
namespaces would be the way to go.
cu, Lars
Best regards,
Marcus
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP taint support: first results
(Wietse Venema) wrote: laurent jouanneau: (Wietse Venema) wrote: To give an idea of the functionality, consider the following program with an obvious HTML injection bug: ?php $username = $_GET['username']; echo Welcome back, $username\n; ? With default .ini settings, this program does exactly what the programmer wrote: it echos the contents of the username request attribute, including all the malicious HTML code that an attacker may have supplied along with it. When I change one .ini setting: taint_error_level = E_WARNING the program produces the same output, but it also produces a warning: Warning: echo(): Argument contains data that is not converted with htmlspecialchars() or htmlentities() in /path/to/script on line 3 A PHP application doesn't always generate HTML : it can generate JSON, CSV, PDF etc.. In this case, we don't have to call htmlspecialchars etc.. In that case, I suppose you would not be using echo, so there is no problem. You wouldn't? So, when outputting a script-generated pdf file, how would you do that if not using echo? (and thus also not print since that's pretty much the exact same thing) Wietse Is this warning appearing also when you want to output datas other than HTML ? If no, how your code guess the output type ? If yes, how can we disable this warning in pages which produce JSON etc. ? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PATCH] bracketed namespace, unset import, removal of namespace blah;
Gregory Beaver wrote:
Hi again,
The attached patch:
1) adds unset import syntax for declaring a namespace to have local
import scope (it does NOT affect variable scope or the global
class/function table)
2) removes namespace Name; syntax (this I am happy to add this back in
if there is uproar)
3) fixes all misspellings of coflict in zend_compile.c (2 total)
4) uses a more intuitive error message Namespace 'Foo' cannot be nested
(already within 'Bar' namespace) for nested namespaces
5) updates tests to use brackets
it can also be found at
http://pear.php.net/~greg/namespace_brackets_unsetimport.patch.txt
After Stanislav's criticisms of my smart import namespace patch and
David's criticism of confusing dual syntax, I decided to take another
approach to the import issue. Although I would rather only support one
use case of namespace blah {}, I do think that realistically PHP should
be as intuitive as possible. Having a separate scope by default for
import that does not inherit from the global scope is not very intuitive.
So, instead of resetting current_import by default, this patch makes
import global by default and local by explicit syntax via:
namespace MyNamespace unset import {
}
For example:
?php
import foo::bar;
namespace foo {
class bar {
function __construct()
{
echo __NAMESPACE__ . ::bar\n;
}
}
// foo::bar
new bar;
}
namespace gronk unset import {
import foo::bar as foobar;
// uses local import
class bar extends foobar {
function __construct()
{
echo __NAMESPACE__ . ::bar\n;
}
}
// gronk::bar
new bar;
// foo::bar
new foobar;
}
namespace last {
// uses global import
// foo::bar
new bar;
}
// uses global import
// foo::bar
new bar;
?
This code demonstrates that in the (useless) namespace last {}
declaration, we can access the global import. This way, since import
conflicts are not the norm but the exception, they can be handled on a
case-by-case basis. Let's remember that in most cases users will not be
declaring multiple namespaces, but instead doing this use case for the
import keyword:
?php
require 'library1/foo.php';
require 'framework2/foo.php';
import framework2::foo as foo;
import library1::foo as bar;
...
?
Again, the primary use case for multiple namespaces in the same file
that I hope to support is combining multiple pre-existing files into a
single file. As each file is expected to be self-contained, this means
that by having import statements within the namespace {} declaration and
using unset import the files are guaranteed to combine with any other
separate file that follows these rules. Even if authors do not use
unset import, it can easily be added by hand or automatically when
glomming the separate files into a single file.
Files with global imports will be out of luck if there are naming
conflicts with the global namespace (similar to today's pre-namespace
conundrum), but as class files or functions are almost always libraries
of some kind, this is unlikely if the documentation is clear on best
practices.
Greg
I'm not sure if this is the best way to take it, to be honest I had to
re-read your post 2x to figure out what was actually going on and why.
The unset import part is odd and not very transparent to the average
user (imo). Sure, with good documentation you could solve that, but imo
we should look for easier to understand syntax instead. I like the idea,
but it adds a lot of complexity with (as far as I can tell) little gain
vs. the original 1-file-1-namespace patch.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [Fwd: Re: [PHP-DEV] Renaming namespaces to packages]
I've been reading this lengthy discussion and here's a sumup of what I found: - PHP's implementation is only a part of what most people expect to find when they hear php has namespace support - PHP's implementation looks a bit like JAVA's package support, and a bit like many other (differently names) features in other languages. It however does not match 1:1 to any of those. So, everyone here has agreed already that namespaces !=== PHP's implementation (it might ==, but not ===). Same goes for Package. I find the idea of Greg to be very good though, reading the original proposal, it often names things not namespace but simply prefix. What do you do with your names? you use a prefix, you don't expect it to have full namespace support just like [insert any other language here], nor do you expect it to be exactly like a JAVA package. When announced, you could simply state PHP now has support for prefixing, PHP's own specific implementation of namespaces. Because that's what you have, you can complain that according to the definition of [word] it _is_ that., but you can't really. The definition of a word like namespace, package, etc. is not independent of its implementation in majorly used languages unfortunately. If you ask a random coder what is a namespace, the answer will always be based on an implementation in a language the person uses/likes a lot. You can quote from wikipedia, but that doesn't really mean anything (sorry Stas), what we should try to do here is find the proper name which identifies the implementation we have for what it is. prefix Foo; alias Foo:Bar as Quux; Looks very good to me as it clearly shows what happens, internally and externally. It's not a namespace as such, it's not a package as such, it's simply what PHP _does_. I hope this will help the discussion steer away from the standard arguments that have been used constantly, and that will simply not change. - Tul Gregory Beaver wrote: Hi, All of the debate over whether this is a true namespace implementation is in my opinion completely bogus (translate: I think namespace is a fine choice for the reserved word, and package is a dangerously misleading choice), but since there is so much noisy dissent, I have an alternative proposal I'd like to float: How about using the keyword prefix or nameprefix instead of namespace? This will be clearer and can be easily defined with 2 sentences similar to the original proposal: All class and function names inside the file are automatically prefixed with the (prefix|nameprefix) name. In other files, classes and functions can be imported with different names (aliases) to eliminate naming conflicts or reduce typing needed. I quote from the original Simple Namespace Proposal message by Dmitry: From the beginning: Main assumption of the model is that the problem that we are to solve is the problem of the very long class names in PHP libraries. We would not attempt to take autoloader's job or create packaging model - only make names manageable. From the middle: Namespace definition does the following: All class and function names inside are automatically prefixed with namespace name. As stated, because this proposal *only* defines a prefix for functions and class names, it is not a packaging model. All package models in existence define some kind of self-contained entity that groups related *files* and their contents together in a way that allows them to be packaged into a single thing, like a jar, a PEAR .tgz, or a .phar file. This proposal does none of these things. Simply because the prefix is defined per-file does not a package make. By the same logic, using .php at the end of a file or .dat at the end of a file creates special packages of php or dat information, because the extension applies to the whole file at once. Simply defining the contents of a file does not imply any organization whatsoever. What the original proposal *does* do is provide a namespace prefix - it defines a scope within which all names have a special prefix. This is not rocket science. rantOn a personal note, if you feel you must reply to this thread further, please follow this checklist: 1) is anything I am saying bring a new idea to the debate? 2) is there a patch that converts my new idea into a reality attached to the message? If you can't answer yes to either of these, please go immediately to jail, do not pass go, do not collect $200./rant Thank you to Dmitry for this much-needed idea. Thanks, Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What is the use of unicode.semantics in PHP 6?
Richard Lynch wrote: On Wed, July 11, 2007 3:11 am, Richard Quadling wrote: On 11/07/07, Evert | Rooftop [EMAIL PROTECTED] wrote: Larry Garfield wrote: Top 10 by what metric? If I had to guess based on market share, I'd say (unordered): Drupal Squirrelmail WordPress phpMyAdmin MediaWiki Joomla PHPBB I saw a reference in this thread to webhosts that don't upgrade because cPanel didn't work, no? [Larry said that, I think...] So, I dunno, maybe the various panels that all those webhosters use should be a candidate... I mean, they all seem to have those panel thingies, even if I personally use them as rarely as humanly possible... [Talk about making easy things impossible... :-)] I got no idea which ones are the most common, though. Cpanel Plesk Ensim -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Recursive classes ... possible bug?
Christian Schneider wrote: Daniel Penning wrote: Checking if the reference is equal and then doing the member-by-member comparison if they differ would prevent too deep recursion in most cases. That would solve this particular case (and might be worth doing for performance reasons anyway I'd say) but won't solve the general problem. Imagine comparing o1-o2-o1 (object 1 having a reference to object 2 which in turn has a reference back to object 1) with o3-o4-o3. You'd still get the same result as now (nesting too deep) and there is no easy way around it. - Chris It might just be me, but I thought there was a student with a google summer of code project who was working on circular references and how to properly free memory for them. Perhaps some of the algorithms devised for that could be used to resolve problems as noted above? - Tul -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Help with the snaps site
Hi John, I actually kind of liked the branch names instead of just PHP4/PHP5. PHP5 doesn't mean squat to me, I'd prefer to see the branch names as they barely take any more space and yet provide a lot more info. - Tul John Mertic wrote: Hi Chris, I can see where you are coming from. I put together another version of this that entirely uses the PHP CSS templates: http://files.edin.dk/php/installer/snaps-html/index-phptemplate.html It looks and feels more like the main PHP.net site. I also went ahead and changed the branch names to PHP 4, PHP 5, and PHP 6, instead of 4.4.x-dev, etc. I'm curious now which one everyone prefers, the previous one ( http://files.edin.dk/php/installer/snaps-html/index.html ) or the one listed above. John On 5/25/07, Christopher Jones [EMAIL PROTECTED] wrote: On reflection, now I've had lunch, the intent/risks of the snapshots isn't so clear. Maybe a simple change such as making the headings 4.4 Development spelling out Development (no need for the .x anyway), or maybe a brief paragraph description is needed. Also adding a link to http://www.php.net/downloads somewhere might help the googler who lands on the snaps page but wants something stable to use. A problem even with the current snaps page is that the PHP logo doesn't link to php.net. And I'd prefer the snap page had the stand php.net header links. Chris John Mertic wrote: Thanks for the compliments and the suggestion. I've made the whole section underneath each branch in the light blue highlighted color. I agree it makes it much easier to read now. John On 5/25/07, Christopher Jones [EMAIL PROTECTED] wrote: John Mertic wrote: Below is a link to my take on the redesign: http://files.edin.dk/php/installer/snaps-html/index.html (Warning - none of the links on the page go to anywhere) My thinking is keep one set of builds on the main page and then provide a link to previous builds, which we can give an ftp-style listing or make the nicer looking page like above. This keeps the snaps page cleaner since I would think most people would be looking for the latest snap and not necessarily one of the previous 4 ones. Let me know if my approach and design sounds reasonable. Looks really nice. I like the next snap column on the LH side. My only improvement would be to change the horizontal background shading so it encompasses the heading of each section as well as the content, and/or encompasses the Previous Builds line. When I look into the middle section of the page my eyes read from the top of each color band, e.g. I see Previous Builds 5.2.x-dev Source Distribution. Chris -- Christopher Jones, Oracle Email: [EMAIL PROTECTED]Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ Book: http://tinyurl.com/f8jad -- Christopher Jones, Oracle Email: [EMAIL PROTECTED]Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ Book: http://tinyurl.com/f8jad -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: unicode.semantics: runtime or not?
Ilia Alshanetsky wrote: From a technical perspective it makes sense to keep it php.ini only setting or as Sara insists (STARTUP phase only). However, from a user (hosting companies) perspective it adds a fair degree of complexity to their setup, which would probably mean one php6 instance will need to run as CGI or FCGI, which will without a doubt affect adoption rates and/or or unicode.semantics being enabled by default on most installs. Personally, I think we'd be better off with a slower adoption rate, but a more robust PHP without added engine/language complexity per- dir unicode.semantics would add. Ilia Alshanetsky My personal opinion, as humble as it may be, is that it's pure bullshit to even give the chance of disabling it. WHY in hell's name would you want to give hoster's the choice? I can see a part of the hosts disabling it to give an easy transition while another part of the hosts enable it to give the new features a chance. If Unicode support it supposed to be such a big part of the while PHP6 release then why do you give the option of disabling it? you're breaking away part of the MAIN reason why people would want to upgrade in the first place. Just imagine what a mess it would be if you had given the choice of disabling the OOP support in PHP5. Be very very very glag you didn't do that, and as such I'd suggest not doing something equally drastic in PHP6. Anyway, just a user's point of view here. Maciej Sokolewicz -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP Cookie Class
Alexander Pak wrote:
I think it's a great idea, maybe it sould be implemented the same way for
sessions too?
On 6/15/06, Jason Boudreault [EMAIL PROTECTED] wrote:
So, I found myself wondering today why PHP has no built in way to treat
cookies as objects.
Why?
I've already written my own class, but, we should implement this!
$cookie = new Cookie();
if (!isset($cookie-username)) {
$cookie-username = george;
$cookie-save();
}
^^ is nice, I was also thinking, there should be an option to auto-save
the cookies on __set :)
-j
I think it's a useless idea and (mainly) this discussion should be moved
to php-generals (or can be reported as a feature suggestion in a
bugreport; bugs.php.net). It has nothing to do with PHP internals.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Win32 snapshot compile failure
Marian Kostadinov wrote: Hello everyone, I wonder why is nobody keeping track of the snaps.php.net win snapshots?:) The last one is built successfully 3 days ago! Unfortunately, it is not the first time when there is no snap for more than two days. I just had a quick look at the snapshot log (also available via snaps.php.net), and it seems like the machine is out of diskspace. ext\pdo_firebird\firebird_driver.c(35) : fatal error C1085: Cannot write precompiled header file: 'Release_TS\ext\pdo_firebird\vc60.pch': There is not enough space on the disk. Is the first fatal error and immediately explains why it hasn't built for so long. So, it seems like it's a server/machine issue, and not a code issue. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] why is '01' == '1.'?
actually, you're right in that (colder.ch) since what happens here is a conversion. This applies to all these 'logic cases' posted. When something is converted to something else, as part of a process, you can't state that the process returns unique results (meaning the result always points back to the same input), and as such you can't state a lot of various things posted in this thread. But this is all OT, and really should be moved off the list, or at least to the generals list. - tul colder.ch wrote: No, this rule of logic can't be applied : 2 == true and true == 10, but 2 != 10 It all depends on the types of the compared values. Hans Melis wrote: a == b and a == c implies by the rules of logic that b == c -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: phpnamespaces.org!
hi, personally, I find :::A, ::A and such constructs *extremely* ugly. Might I suggest using a special keyword to denote global scoped classes? eg: global:::A and such. global already is a keyword, but I'm pretty sure it could be reused in this context. Plus, it clearly shows where you're getting it all from. - tul Jessie Hernandez wrote: Hi l0t3k, Yes, this is how it's done in C++, but do we want to allow this syntax for PHP? If so, it'll either be :::A, ::A (can be used, but might be inconsistent as ::: is used everywhere else), or \A, depending on the final separator... Regards, Jessie l0t3k [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Jessie Hernandez [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] 2) How will symbols be resolved inside namespaces? If a class A exists in namespace N, and a global class A also exists, then by referencing A, what should happen? Should the namespaced A be used? If so, then the global A cannot be accessed from the namespace. Is this OK? These rules would need to be the same and affects the following contexts: i should know this, but does PHP use :: as the global scope resolver as in C++ ? if so, namespaced A==$A global A == ::$A l0t3k -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] is_callable and method_exists always true when __call is defined
I would expect is_callable() to return true (since it is callable), but method_exists() to return false (since it doesn't really exist, it's magic)... at least, that's what would make most sense to me... Marcus Boerger wrote: Hello Davey, if you ask me it is stupid to return true because __call exists since the user can pretty easy do that by adding one more check. But he can in no way query if the function really exists or not (well he can use reflection but that is thousand times slower...) regards marcus Saturday, July 9, 2005, 6:08:03 AM, you wrote: Dear all, I came across something when I found this bug (http://bugs.php.net/bug.php?id=33621). Should is_callable() and method_exists() always return true when the method doesn't *really* exist? i.e. it would only be called via __call() Is it possible to add an argument to make it only check real methods at the very least? Or some way to additionally distinguish between these two things? - Davey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
Robert Cummings wrote: On Tue, 2005-06-14 at 01:31, Ron Korving wrote: Jason, you are absolutely right.. this is not about input filtering at all. It's about replacing: $x = (isset($ANY_var) ? $ANY_var : 'Default Value'); by $x = ifsetor($ANY_var, 'Default Value'); So, Robert's solution is no real solution if you ask me. But again, it would be best, if there was no ifsetor() at all, I must say I fully agree; I don't see any use in putting extra functions in the PHP namespace just because people don't want to type a couple of extra characters. but that users would have the power to create such a function themselves in the php code space. I have no clue how though... Well my code has nothing to do with filtering. It's all about retrieving a default value if one is not set in response to the poster to which I replied. But yes, I was hasty with it in my eternal lack of wisdom, and of course forgot about scalars. For the record, I am indeed in favour of something that allows the choice of a value from a series of values for which some may not be set-- without the generation of not set warnings :) On that note, how comes there's a $GLOBAL array and not a $LOCAL array for vars declared in the immediate scope :) because, by definition, $LOCAL would at all times be a part of $GLOBAL. And besides, why would you ever want $LOCAL? $GLOBAL is a way to reach the global scope from the local scope. When being in global scope, you never *have* a local scope, and the other way around, when being in local scope, you can reach all variables directly anyway, so there's no use for $LOCAL. Then, expecting the response why is there a $GLOBAL array in global scope? you might want to say that $GLOBAL is a superglobal just because the global scope can be seen as a local scope in a broader perspective. Well... that's my view on it anyway... Cheers, Rob. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Fw: win32 build broken
I'm havind the exact same problem as Sebastian. Building it using VS.NET 7.0, building it against mysql 4.1.11. Rob Richards wrote: It builds fine here. Assuming the problem you are hitting is still in mysql, I'm building it shared and using headers from mysql-3.23.58 and under VC++ 6 so not sure if that matters. Rob Sebastian Bergmann wrote: Sebastian Bergmann wrote: HEAD built fine for me after April 26. But it broke (at least for me) some time after Friday. Am I the only one having this problem? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: phpPgAdmin
wwhhhyyy. did you CC internals on this? :| Christopher Kings-Lynne wrote: Hi Plamen, My name is Plamen Petrov and I wanted to help out in developing phpPgAdmin. Currently I don't have much time to contribute since I am working on a project that takes away my weekends too but in couple of months or something like that I may have some more time. That's ok - when you have time and want something to do, just email me and I'll assign you something easy to start with. I am also having a web hosting solution if there is a need to host parts of the project. I have purchased the phpPgAdmin domain names and wanted to ask you if I can forward those to the home page of the project. This could be my initial contribution for now. Wow cool. I'm not sure how to make it point to out site. Robert - do you know how you do this? Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php5 win build
Jon Parise wrote: On Wed, Mar 30, 2005 at 11:23:37AM -0500, Dan Scott wrote: Reading http://www.zend.com/manual/install.windows.building.php suggests that to fix this problem I need to rebuild resolv.lib -- but using the bindlib.dsp file requires msdev, which requires a full MS Visual Studio environment. That's a showstopper for those of us trying to do this with just the free-beer tools available from Microsoft. However, it is apparently possible to export a DSP file as a Makefile from MS Visual Studio. If someone with a full MS Visual Studio environment would be willing to make that exported makefile available, I think it might help close this final loop and would be a worthwhile addition to the bindlib_w32.zip archive. I've been meaning to attempt a Win32 PHP build using the free toolchain[1]. I also have the full tools, so I'll take a crack at getting everything running some time soon (probably this weekend). [1] http://msdn.microsoft.com/visualc/vctoolkit2003/ well, with a (slight) bit of modding, eventually you can get it all to work (it works for me). The only problem I'm running into is that php seems to segfault quite often, but only on the first load of a certain pages (huh?). Unfortunately it appears to be pretty hard to get a backtrace of what is going on on windows systems (no, I'm *not* using cygwin). Might I also add that is pretty darn hard to get the GD lib compiled so I can compile the extension into PHP? (iow, I haven't found a way yet). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] why does PHP accept [new] session ids from client?
why is it this way should also be posted to the general newsgroup, it barely has anything to do with internals - tul Hans L wrote: Ok, I'll post it there. I thought that it was more a question of why is it this way? than how do I do ?. Thanks, Hans Jeremy Johnstone wrote: Not to be rude or anything, but this question is better suited for php-general -Jeremy On Tue, 29 Mar 2005 12:47:29 -0500, Hans L [EMAIL PROTECTED] wrote: Hi, This may not be the right place for this question, but what I'm looking to understand is the reasoning behind what seems to be the standard session behavior in PHP. And, if it's possible, how to change this behavior (via INI settings, etc.). As I understand (and experience) it, if a client [browser] presents a session id (e.g. in a cookie) to the server, then PHP will attempt to match that ID to the session on the system. If found, that session information will be made available to the scripts. Fine. But, if *not found* then a new session will be created with the specified ID. Is there any way to disable this behavior? I can't think of a single circumstance under which this would be the desired behavior, but my use of sessions has been more limited to authentication web applications. I know about using session_regenerate_id() after authentication, to prevent fixation, but it seems like this is a workaround for a more fundamental problem in PHP session behavior. On a side note, does anyone know if Hardened-PHP exhibits the same behavior? Thanks, Hans -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Problem with fix for bug #31672
I very much agree with this. It's very common to output JavaScript via PHP, and that also uses the script/script tags...so... Ilia Alshanetsky wrote: Good point, +1 for revert. Ilia Zeev Suraski wrote: Guys, I'd like to revert the fix for bug #31672 (/script is not considered closing tag if preceded by one-line comment). While theoretically correct, I'd rather resolve it by fixing the docs. The reason is simple - unlike ? and %, the string /script is very much likely to appear inside one line comments: // print scriptfoo/script; That suddenly fails. That's probably the reason we didn't implement it in the first place. Any objections to reverting this fix? Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] error in compile php5 in vs.net
I've stumbled unto the same problem a week ago aswell. Indeed, using --without-iconv works; however, those errors are partially because of some incompatibility with the iconv library (according to Wez, some long time ago). I'll try and rebuild it with an earlier version to see if it works, because it might be that it's simply incompatibility between versions - tul Frank M. Kromann wrote: Try to add --without-iconv. Or install the iconv libraries from http://ctindustries.net/dom/libxml/ - Frank C:\Work\php-5.0.3cscript /nologo configure.js --without-simplexml --without-xml --without-xmlrpc --without-libxml Saving configure options to config.nice.bat Checking for cl.exe ... in default path Checking for link.exe ... in default path Checking for nmake.exe ... in default path Checking for lib.exe ... in default path Checking for bison.exe ... in default path Checking for flex.exe ... in default path Checking for re2c.exe ... not found Checking for zip.exe ... not found Checking for lemon.exe ... not found Checking for arpa\nameser.h ... ..\win32build\include Checking for library resolv.lib ... ..\win32build\lib\resolv.lib Build dir: Release_TS PHP Core: php5ts.dll and php5ts.lib Checking for wspiapi.h ... ..\win32build\include Enabling IPv6 support Checking for NewAPIs.h ... ..\win32build\include Enabling SAPI sapi\cgi Enabling SAPI sapi\cli Checking for library libjpeg.lib ... not found WARNING: gd not enabled; libraries and headers not found Enabling extension ext\ftp Enabling extension ext\spl Enabling extension ext\odbc Enabling extension ext\pcre Enabling extension ext\zlib Checking for library zlib.lib ... ..\win32build\lib\zlib.lib Checking for zlib.h ... ..\win32build\include Enabling extension ext\ctype Checking for iconv.h ... ..\win32build\include Enabling extension ext\iconv Enabling extension ext\session Enabling extension ext\calendar Enabling extension ext\bcmath Enabling extension ext\tokenizer Enabling extension ext\sqlite Enabling extension ext\standard Checking for library oleaut32.lib ... in LIB path OleAut32.Lib Enabling extension ext\com_dotnet Checking for mscoree.h ... in default path Creating build dirs... Generating files... Generating Makefile Generating main/internal_functions.c Generating main/config.w32.h Done. Type 'nmake' to build PHP C:\Work\php-5.0.3nmake Microsoft (R) Program Maintenance Utility Version 7.10.3077 Copyright (C) Microsoft Corporation. All rights reserved. cl.exe /D _USRDLL /D PHP5DLLTS_EXPORTS /D PHP_EXPORTS /D LIBZEND_EXPOR TS /D TSRM_EXPORTS /D SAPI_EXPORTS /D WINVER=0x400 /I ..\win32build\include / DHAVE_NEWAPIS_H=1-DSUPPORT_UTF8 -DLINK_SIZE=2 -DPOSIX_MALLOC_THRESHOLD=10 -I ext/pcre/pcrelib -DNO_RECURSE /D ZLIB_EXPORTS /I ..\win32build\include /D PH P_ICONV_EXPORTS -Iext/bcmath/libbcmath/src /D PHP_SQLITE_EXPORTS /I ext\sqlit e/libsqlite/src /nologo /YX /FD /I . /I main /I regex /I Zend /I TSRM /D _WIND OWS /D ZEND_WIN32=1 /D PHP_WIN32=1 /D WIN32 /D _MBCS /LD /MD /W3 /Ox /D NDebug / D NDEBUG /D ZEND_WIN32_FORCE_INLINE /GB /GF /D ZEND_DEBUG=0 /D ZTS=1 /I ..\win3 2build\include /D FD_SETSIZE=256 /FoRelease_TS\main\ /FdRelease_TS\main\ /FpRe lease_TS\main\ /FRRelease_TS\main\ -c main\internal_functions.c -o Release_TS\ma in\internal_functions.obj internal_functions.c ..\win32build\include\WS2tcpip.h(647) : warning C4142: benign redefinition of ty pe link.exe /out:Release_TS\php5ts.dll /dll /nodefaultlib:libcmt /def:Rel ease_TS\php5ts.dll.def /nologo /version:5.0.3 /libpath:..\win32build\lib / libpath:..\win32build\lib Release_TS\Zend\zend.obj Release_TS\Zend\ze nd_API.obj Release_TS\Zend\zend_alloc.obj Release_TS\Zend\zend_builtin_functions .obj Release_TS\Zend\zend_compile.obj Release_TS\Zend\zend_constants.obj Release _TS\Zend\zend_default_classes.obj Release_TS\Zend\zend_dynamic_array.obj Release _TS\Zend\zend_exceptions.obj Release_TS\Zend\zend_execute.obj Release_TS\Zend\ze nd_execute_API.obj Release_TS\Zend\zend_extensions.obj Release_TS\Zend\zend_hash .obj Release_TS\Zend\zend_highlight.obj Release_TS\Zend\zend_indent.obj Release_ TS\Zend\zend_ini.obj Release_TS\Zend\zend_ini_parser.obj Release_TS\Zend\zend_in i_scanner.obj Release_TS\Zend\zend_interfaces.obj Release_TS\Zend\zend_iterators .obj Release_TS\Zend\zend_language_parser.obj Release_TS\Zend\zend_language_scan ner.obj Release_TS\Zend\zend_list.obj Release_TS\Zend\zend_llist.obj Release_TSZend\zend_mm.obj Release_TS\Zend\zend_multibyte.obj Release_TS\Zend\zend_object_ handlers.obj Release_TS\Zend\zend_objects.obj Release_TS\Zend\zend_objects_API.o bj Release_TS\Zend\zend_opcode.obj Release_TS\Zend\zend_operators.obj Release_TS \Zend\zend_ptr_stack.obj Release_TS\Zend\zend_qsort.obj Release_TS\Zend\zend_ref lection_api.obj Release_TS\Zend\zend_sprintf.obj Release_TS\Zend\zend_stack.obj Release_TS\Zend\zend_stream.obj Release_TS\Zend\zend_strtod.obj Release_TS\Zendzend_ts_hash.obj Release_TS\Zend\zend_variables.obj
[PHP-DEV] Re: problems compiling mysqli (on win32)
Sebastian Bergmann wrote: M. Sokolewicz wrote: So, is this a problem with my compiler being stupid? Are you sure you have the right MySQL headers and libraries? ah, thanks for the headsup on this, it seems it was indeed a header/library mismatch; the configure script took em from the win32build dir instead of the mysql install (had to move the win32buikd ones to have it fetch the mysql install headers/libs instead) so, that works now; only problem left is an unresolved extrenal symbols problem. php5ts.dll.def : error LNK2001: unresolved external symbol _libiconv_version php5ts.dll.def : error LNK2001: unresolved external symbol libiconv php5ts.dll.def : error LNK2001: unresolved external symbol libiconv_close php5ts.dll.def : error LNK2001: unresolved external symbol libiconv_open php5ts.dll.def : error LNK2001: unresolved external symbol libiconv_set_relocati on_prefix Release_TS\php5ts.lib : fatal error LNK1120: 5 unresolved externals LINK : fatal error LNK1141: failure during build of exports file Now, I have no idea why this is hapenning, because according to the makefile, it links to them via PHP_DLL_DEF_SOURCES (which has the correct paths. I've tried changing them, and make failed earlier because it couldn't find them...). I can't figure out why it has to be so much more complicated on win32-systems; guess that's because few people actually try it there =/ - tul -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] problems compiling mysqli (on win32)
whenever I try compiling PHP, the mysqli extension gives me trouble.
I've gotten this all from HEAD just a couple of hours ago (again, it
didn't work before either). I'm using MSVC 7.1 (.NET). Here's the error
I'm getting:
ext\mysqli\php_mysqli.h(50) : error C2061: syntax error : identifier
'MYSQL_STMT'
ext\mysqli\php_mysqli.h(54) : error C2059: syntax error : '}'
ext\mysqli\php_mysqli.h(93) : error C2065: 'LOCAL_INFILE_ERROR_LEN' :
undeclared identifier
ext\mysqli\php_mysqli.h(93) : error C2057: expected constant expression
ext\mysqli\php_mysqli.h(94) : error C2229: struct '__unnamed' has an
illegal zero-sized array
ext\mysqli\php_mysqli.h(127) : error C2143: syntax error : missing ')'
before '*'
ext\mysqli\php_mysqli.h(127) : error C2143: syntax error : missing '{'
before '*'
ext\mysqli\php_mysqli.h(127) : error C2059: syntax error : ')'
Since I'm no good at C, I really have no idea what the problem here
is... So, is this a problem with my compiler being stupid? or is this a
real live problem in HEAD?
hope somebody can help me with this,
- M. Sokolewicz
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
Ok, this is getting plain annoying. Please stop this endless chatter, all of you! It's annoying, senseless, and counter-productive. If you *really* want to keep bitching at eachother, then please do it somewhere else (iow, not on the list). Andrei Zmievski wrote: Terje, Yeah, follow it up with an insult; that'll do lovely. If you had some insight into human nature, you'd know that humour is very subjective, and given the feedback I've got from others in this thread (which have _not_ been jokes), it's rather hard to see what's a joke and what's not. Perhaps you should examine your own insight into human nature. You have been arguing endlessly about a feature that is questionable, if not completely unnecessary in PHP, and given the number and the nature of replies you received from many PHP developers, you would have been better off giving it up or finding another approach. However, you persist and view your own opinions as the only valid ones. Let me explain: Although I understood that the literal thing you wrote above was of course a joke, my question was meant to see whether there was a serious side to the joke, as well. In other words, if people reacted negatively to this (and, judging from other reactions, it seems so, or at least, they concentrated on the code, rather than my point illustrated with it). If you know it was a joke, you should have taken it as one. I've been known to have a good sense of humour. However, I'm also sensitive, so when I don't know if something is meant as a joke or not, I don't find it amusing. Apparently, this was something you didn't understand, at all, and instead insult me about something you know _nothing_ about. Is that C++ or your sense of humor? What have I done to you, to get an insult from you? How would you feel it if someone else said this to you? A friggin' immature thing to say. Enough of this. - Andrei -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: referencing Superglobals with variable variables inside functions
AFAICS, it should make every local-variable (non-global) lookup slower.
Since it needs to do a lookup in the globals table first.
Xuefer Tinys wrote:
$_GET is solved at compile time, which is good, but this make other
variables bad at execution time?
how much does this patch slow execution down? it's one more hash lookup.
affect speed of $var or $$var? or both?
On Mon, 31 Jan 2005 14:24:41 -0800, Sara Golemon [EMAIL PROTECTED] wrote:
So in order for ZE to resolve the autoglobals correctly during runtime it
has to ask two questions for every *part* of every variable resolution:
Are
we checking against the active symbol table? Is the index we're looking
for
in the autoglobal registry? If so, replace active_symbol_table with the
global symbol_table, otherwise do the lookup as normal.
I knew this statement felt wrong when I wrote it so I dove in and looked at
the code againIt's not actually necessary to test the what scope we're
in because of the way the parser is laid out... however it does still add an
extra hashtable lookup that shouldn't be necessary, so my original position
stands as is for now.
If someone would like to benchmark the following patch (Or point out any
fatal flaws in it) I'd be interrested in the results, but even if there's no
perceptible difference over a million itterations, I'd probably still
vote -1 on changing it.
-Sara
Index: Zend/zend_execute.c
===
RCS file: /repository/ZendEngine2/zend_execute.c,v
retrieving revision 1.692
diff -u -r1.692 zend_execute.c
--- Zend/zend_execute.c 22 Jan 2005 02:29:18 - 1.692
+++ Zend/zend_execute.c 31 Jan 2005 22:13:50 -
@@ -1001,6 +1001,10 @@
{
switch (opline-op2.u.EA.type) {
case ZEND_FETCH_LOCAL:
+ if (zend_hash_exists(CG(auto_globals),
variable-value.str.val, variable-value.str.len + 1)) {
+ /* Dynamically resolved auto global */
+ return EG(symbol_table);
+ }
return EG(active_symbol_table);
break;
case ZEND_FETCH_GLOBAL:
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: different behaviour converting float to integer
You might want to ask this on the internals list (cc'd) Tomas Kuliavas wrote: When php 5.0.2 converts float to integer, it uses biggest possible integer value. Other php versions overflow and use negalive integers. How to reproduce it: echo (int)0xde120495; Expected result (php 5.0.1, 4.3.9 and 4.1.2): -569244523 Actual result (only php 5.0.2): -- 2147483647 Is this a standard behaviour of all future php versions or some error in php? OS details: Linux Debian Sarge PHP compilation details (vanilla php-5.0.2.tar.bz2): ./configure --disable-debug --with-apxs=/somepath/apache/bin/apxs --prefix=/somepath/php --with-config-file-path=/somepath/ --with-pcre-regex --enable-mbstring --enable-session --disable-all --with-gettext=shared,/usr php.ini details: error_reporting=E_ALL display_errors=on register_globals=off asp_tags=on short_tags=off Please CC to my email. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
