Re: [PHP-DEV] Abusive emails was: silly question : what is more secure at the moment, php7, php8, or plain .sh shell scripts?

Am 15.01.21 um 00:04 schrieb : "With over 1.2 billion devices now running Windows 10, customer satisfaction is higher than any previous version of windows" OK, your head is full of shit - what is "windows"? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https

Re: [PHP-DEV] Abusive emails was: silly question : what is more secure at the moment, php7, php8, or plain .sh shell scripts?

Am 14.01.21 um 23:45 schrieb Kalle Sommer Nielsen: I don't think anyone is interested in sueing you, quite the contrary, what we wish is for you to stop messaging people via the PHP project's infrastructure you fucking moron when i write to somebody directly your holy infrastructure and pro

Re: [PHP-DEV] Abusive emails was: silly question : what is more secure at the moment, php7, php8, or plain .sh shell scripts?

Am 14.01.21 um 23:45 schrieb Kalle Sommer Nielsen: Den fre. 15. jan. 2021 kl. 00.30 skrev Reindl Harald (privat) : to make it easier for you: AUSTRIA not germany - similar laws but wrong country, you waste time to sue me in germany I don't really care where it is, matter of the fa

Re: [PHP-DEV] Abusive emails was: silly question : what is more secure at the moment, php7, php8, or plain .sh shell scripts?

Am 14.01.21 um 22:55 schrieb Kalle Sommer Nielsen: Since this is an endless battle, I do not see any other option than taking the battle to legal authorities in Germany (assuming that is where he is located based on name/email locale), not sure if the NetzDG or STGB 185 applies here, but it is

Re: [PHP-DEV] PHP 8 is_file/is_dir input handling

Am 02.12.20 um 09:18 schrieb Christian Schneider: Am 01.12.2020 um 21:13 schrieb Reindl Harald (privat) : Am 01.12.20 um 21:09 schrieb Stanislav Malyshev: we are running error_reporting E_ALL for 17 years now and don't distinct between notice / warning / error, it has to be fixed - p

Re: [PHP-DEV] Re: PHP 8 is_file/is_dir input handling

Am 01.12.20 um 21:09 schrieb Stanislav Malyshev: we are running error_reporting E_ALL for 17 years now and don't distinct between notice / warning / error, it has to be fixed - period Surely you do. Your code continues to run after warning/notice but stops after the error. It's impossible to

Re: [PHP-DEV] Re: PHP 8 is_file/is_dir input handling

Am 01.12.20 um 21:06 schrieb Stanislav Malyshev: Hi! First, assuming that a null byte in a file name *is* an error condition, is the PHP 8 behavior better than in PHP 7? I think the answer to this one is very clearly "yes". The above code snippet and the subtle way in which it For me as

Re: [PHP-DEV] Re: PHP 8 is_file/is_dir input handling

Am 01.12.20 um 18:56 schrieb Aimeos | Norbert Sendetzky: Am 01.12.20 um 18:47 schrieb G. P. B.: Or is_file could check for it, handle it gracefully, and be a safe function to call without worrying about this undocumented edge case. Apologize my email client sent by mistake: But this has al

Re: [PHP-DEV] Alias for `int|float`

Am 08.11.20 um 18:09 schrieb Eugene Sidelnyk: Hello, internals! What do you think about creating shorthand `number` for `int|float`? nothing because: a) float accepts int anyways b) overloading the engine for each and every nuance is not helpful c) union types are clear and readable -- PH

Re: [PHP-DEV] Type casting while array destructuring

Am 24.03.20 um 15:23 schrieb Rowan Tommins: > On the other hand, this is exactly the kind of thing where strict_types=1 > makes things worse - you'll actually get *better* error output if you use > strict_types=0 and pass the string to a function marked as requiring int no! with strict_types=

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

Am 11.02.20 um 13:42 schrieb Albert Casademont: > This is very interesting, thanks! > > Would it make sense to also add an INI setting to disable superglobals and > response functions? no because changing basic language behavior that way is not helpful for code meant to run everywhere and not

Re: [PHP-DEV] PHP class files without

Am 07.04.2012 16:23, schrieb Tom Boutell: > On Sat, Apr 7, 2012 at 10:06 AM, Reindl Harald wrote: >> why do you simply not realize that you have way too few knowledge >> and tchnical education to partly understand the side effects >> small changes in a general behavior

Re: [PHP-DEV] PHP class files without

Am 07.04.2012 16:07, schrieb Derick Rethans: > On Sat, 7 Apr 2012, Reindl Harald wrote: > >> and no the world is not turning around you or even around PHP > > I will once more suggest you tune down your language on the > mailinglists. It's often rude and offens

Re: [PHP-DEV] PHP class files without

Am 07.04.2012 16:00, schrieb Tom Boutell: > That's a good point too. > > I think this is a better proposal: > > include_code, require_code, and require_code_once would work just like > include, require and require_once, except that the parser would start > out in PHP mode. would you please lea

Re: [PHP-DEV] PHP class files without

Am 07.04.2012 15:43, schrieb Stuart Dallas: > On 7 Apr 2012, at 14:39, Tom Boutell wrote: > >> From the viewpoint of someone writing reusable classes, the need to >> start with > above it is a silly annoyance they don't experience with other tools. >> >> That said, you are making valid points, I

Re: [PHP-DEV] PHP class files without

based on mime types etc. >>> >>> This way .php continues to behave exactly as it does today, and can >>> interoperate smoothly with code that uses .phpc. .phpc can require >>> .php and vice versa. They are friends. >>> >>> Thoughts? >>> >>> -

Re: [PHP-DEV] PHP as a template language

Am 07.04.2012 01:30, schrieb Chris Stockton: > Hello, > > On Fri, Apr 6, 2012 at 3:08 PM, Reindl Harald wrote: >> >> >> Am 06.04.2012 23:54, schrieb Tom Boutell: >>> On Fri, Apr 6, 2012 at 5:39 PM, Reindl Harald >>> wrote: >> >> th

Re: [PHP-DEV] PHP as a template language

Am 06.04.2012 23:54, schrieb Tom Boutell: > On Fri, Apr 6, 2012 at 5:39 PM, Reindl Harald wrote: >> what do you expect by propose work for many people > Oh I'm sorry, do we need to start every feature suggestion with a > description of exactly who will do the work? the &qu

Re: [PHP-DEV] PHP as a template language

tic. The difference relative to >>>> htmlentities(..., ENT_QUOTES | ENT_HTML5, 'UTF-8'); ?> however is 56 >>>>> characters, security, and encoding bugs. >>>>> >>>>> Proper handling of output escaping is standard in modern template &

Re: [PHP-DEV] PHP as a template language

oler short tag?". >>> The question should be "What needs to be done to make PHP an industry >>> leader in template languages again?". >>> >>> My two cents, >>> >>> John Crenshaw >>> Priacta, Inc. >>> >>> -- >>

Re: [PHP-DEV] PHP as a template language

Am 06.04.2012 04:55, schrieb Sébatien Durand: > IMHO, PHP is a great template language. This is what makes it so simple > and powerful, compared to other web languages. > > So far, we have " > A suggestion : deprecate these old tags and replace them with a more > elegant and a shorter impleme

Re: [PHP-DEV] RFC: Removing PHP tags

Am 01.04.2012 03:59, schrieb Moriyoshi Koizumi: > Hi, > > I wrote a RFC that proposes removal of PHP tags. There is actually > strong public demand for it, and I also think it is necessary to > leverage PHP to a genuine, modern scripting language. > > http://wiki.php.net/rfc/nophptags nice 1s

Re: [PHP-DEV] PHP5.4 'nannying'

Am 18.03.2012 18:53, schrieb Lester Caine: > Ferenc Kovacs wrote: >> * *|E_ALL|* now includes *|E_STRICT|* level errors in the error_reporting >> >> >> configuration >> directive. >> >> I would guess your

Re: [PHP-DEV] PHP5.4 'nannying'

Am 18.03.2012 10:14, schrieb Lester Caine: > I think what I am probably looking for is a clean guide as to how code SHOULD > be written nowadays in order to avoid > the nanny messages since it's certainly not my normal practice after 10 years > of coding in PHP5 ... usually it would have been

Re: [PHP-DEV] Small question about performance

thanks exactly what i assumed, but better to be sure instead wasting somewhere ressources without need :-) Am 15.03.2012 20:10, schrieb Michael Stowe: > The $b on this example would be freed as it is in the function's scope, and > not the global scope. The exception to this would be a static var

Re: [PHP-DEV] Small question about performance

Am 15.03.2012 18:41, schrieb Paul Dragoonis: >>> I don't really know when PHP frees temporary variables, but my guess >>> was that they are freed when the scope is left. >> >> Each variable has a refcount, then that hits 0 it can be freed up. > > To add to that. A zval will have a refcount, so i

Re: [PHP-DEV] Upgrade cURL extension

Am 10.03.2012 18:28, schrieb Simon Schick: > I'd like to see a new interface for curl in php ... I have no special > idea how, but I heard from several people that they pretty much don't > like the way curl is implemented in php. many other people would not like to break their perfect working co

Re: [PHP-DEV] Quoting again

Am 07.03.2012 11:12, schrieb Pierre Joye: > On Wed, Mar 7, 2012 at 11:05 AM, Derick Rethans wrote: > >> The mailinglist guidelines also are for you, so let me repeat what I >> wrote yesterday: > > To write a one line reply to another one line reply is just fine. > > Make us all a favour, don'

Re: [PHP-DEV] '

Am 07.03.2012 00:15, schrieb Kris Craig: >> In such cases, the people breaking the thread convention should >> the very least remove all the other content. >> And yes, his MUA does support threading. >> >> >> > > I'll try this one last time: I don't know what the solution is. learning to use

Re: [PHP-DEV] consider reverting E_ALL with E_STRICT

Am 07.03.2012 01:11, schrieb Alan Knowles: > Sorry - top post as I can't reply to all the mails on the thread.. > > - display errors on. > Yes, this is a business decision, 20 servers running upgraded at different > times, some have less maintenance others > have more.. Seriously, the chance of

Re: [PHP-DEV] '

Am 06.03.2012 19:36, schrieb Kris Craig: > Sorry. Sometimes I forget that there are some people out there who still > use legacy non-threaded inboxes. I would recommend you consider switching > to Gmail or some other email client/service that supports threaded views. > That will make it a lot e

Re: [PHP-DEV] consider reverting E_ALL with E_STRICT

Am 06.03.2012 17:22, schrieb Gustavo Lopes: > On Tue, 06 Mar 2012 17:08:07 +0100, Alan Knowles wrote: > >> [...] >> However with E_STRICT included we have to run around and find all the code, >> and change it to stuff like this: >> >> error_reporting(E_ALL & E_STRICT ? E_ALL ^ E_STRICT : E_ALL

Re: [PHP-DEV] consider reverting E_ALL with E_STRICT

Am 06.03.2012 17:08, schrieb Alan Knowles: > However with E_STRICT included we have to run around and find all the code, > and > change it to stuff like this: error_reporting(E_ALL & E_STRICT ? E_ALL ^ > E_STRICT : E_ALL); > > Could we please revert that, and if people want an all encompasing

Re: [PHP-DEV] '

Am 06.03.2012 01:13, schrieb Kris Craig: > On Windows (where I generally do most of my scripting grunt work), > I typically use Notepad++ and it highlights > > On Mon, Mar 5, 2012 at 4:11 PM, Reindl Harald <mailto:h.rei...@thelounge.net>> wrote: > Am 06.03.2012 0

Re: [PHP-DEV] '

Am 06.03.2012 01:03, schrieb Kris Craig: > I've never understood the "it's easier to read" argument since I've found > it to be exactly the opposite. The me, makes it more difficult to "at a glance" see where the PHP code begins if you hvae a usebale editor would become different colors only

Re: [PHP-DEV] PHP 5.4.0 released!

Am 02.03.2012 00:46, schrieb Kris Craig: > LOL tell me about it! The default PHP repos for many OSes are still using > 5.1.x so what using 5.3.x in production since 3 months after release everywhere learning to build packages for your OS is the key signature.asc Description: OpenPGP dig

Re: [PHP-DEV] pecl, zts, non-zts, fastcgi and Apache

Am 28.02.2012 22:41, schrieb Sebastian Bergmann: > On 02/28/2012 02:44 PM, Christopher Jones wrote: >> Build PHP with ZTS enabled by default. Allow it to be explicitly >> disabled during 'configure' > > Why punish everyone by default because of Apache? Does not make sense to > me. even for ap

Re: [PHP-DEV] Apache 2.4 support in PHP 5.4.0?

Am 25.02.2012 00:09, schrieb Bostjan Skufca: > Despite the fact that Apache HTTPD's website says that 2.4.1 "represents > the best available version of Apache HTTP Server", and that PHP 5.4.0 will > probably also bear similar notation (guesswork here!), very few (if any!) > production environment

Re: [PHP-DEV] Apache 2.4 support in PHP 5.4.0?

Am 24.02.2012 20:57, schrieb Stas Malyshev: > Hi! > >> If you're planning to have a PHP 5.4 RC9, should Apache 2.4 support be >> included? This would reduce any negative user sentiment that "PHP 5.4 >> doesn't even support the latest Apache". > > Latest Apache is about 3 days old now :) If som

Re: [PHP-DEV] About CVE-2012-0831 (magic_quotes_gpc remote disable vulnerability?)

Am 14.02.2012 14:02, schrieb Kousuke Ebihara: > Hi, > > I've noticed the following CVE: > > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0831 > >> PHP before 5.3.10 does not properly perform a temporary change to the >> magic_quotes_gpc directive during the importing of environment

Re: [PHP-DEV] Internal server error on PHP syntax error?

Am 13.02.2012 18:08, schrieb Jakov Sosic: > and I get this in logs: > IPADDR - - [13/Feb/2012:18:03:52 +0100] "GET /~username/test/ HTTP/1.1" 500 > 20 "-" "Mozilla/5.0 (X11; Linux x86_64; > rv:10.0.1) Gecko/20100101 Firefox/10.0.1" > > so, 500 headers are returned but internal server error page

Re: [PHP-DEV] Security risk how to use find recommended in php.ini-*

Am 09.02.2012 00:35, schrieb Ondřej Surý: > Much better would be: > > find /path/to/sessions -cmin +24 -delete > or at least > find /path/to/sessions -cmin +24 -execdir rm "{}" \; (GNU find) > > The most error-prone way is something we cooked up in Debian: > > find /var/lib/php5/ -depth -minde

Re: [PHP-DEV] When is PHP6 Beta going to be available ;)

Am 07.02.2012 13:39, schrieb Matti Bickel: > On 02/04/2012 09:26 PM, Lester Caine wrote: >> I'm just looking into my annual dedicated server update since it's the >> only way to get the current contract prices, and I find that ! and 1 are >> still advertising support for PHP6 Beta :) I wonder how

Re: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds

Am 06.02.2012 17:10, schrieb Michael Morris: > > > On Mon, Feb 6, 2012 at 10:32 AM, Reindl Harald <mailto:h.rei...@thelounge.net>> wrote: > > first: do not top-post if you get a reply below > > second: > in the context of suhosin "w

Re: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds

st the code. If I do not trust > it, I don't run it. > > On Mon, Feb 6, 2012 at 10:15 AM, Reindl Harald wrote: > >> if your make technical decisions especially security ones by >> "The character displayed by Stefan" you are maybe doing the >> wrong job!

Re: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds

Am 06.02.2012 16:00, schrieb Michael Morris: > Having watched this discussion unfold, I for one intend to discontinue > using Sushonin. I advise others to do the same. The character displayed by > Stefan throughout this thread speaks for itself as to why. if your make technical decisions especi

Re: [PHP-DEV] [RFC] Deprecate and remove /e modifier from preg_replace

Am 05.02.2012 18:09, schrieb Nikita Popov: > On Sun, Feb 5, 2012 at 5:45 PM, Michael Stowe wrote: > [snip] >> Perhaps another option, if it's a security concern is the ability to turn >> off the /e modifier, and have it off by default. This way we can protect our >> less experienced programmer

Re: [PHP-DEV] [RFC] Deprecate and remove /e modifier from preg_replace

Am 05.02.2012 17:45, schrieb Michael Stowe: > Perhaps another option, if it's a security concern is the ability > to turn off the /e modifier, and have it off by default. This way > we can protect our less experienced programmers, while keeping it > available for more advanced use cases. > >

Re: [PHP-DEV] [RFC] Deprecate and remove /e modifier from preg_replace

2012 at 11:34 AM, Reindl Harald wrote: >> what he hell - if you kill eval you would kill the whole >> work of my life and yes i know that eval is evil and >> it is only used at one place which is a central and >> real important to include modules and set parameters >> dyna

Re: [PHP-DEV] [RFC] Deprecate and remove /e modifier from preg_replace

what he hell - if you kill eval you would kill the whole work of my life and yes i know that eval is evil and it is only used at one place which is a central and real important to include modules and set parameters dynamically the /e modifier is a total other dimension because it can be used by pe

Re: [PHP-DEV] The case of HTTP response splitting protection in PHP

Am 03.02.2012 21:44, schrieb Ángel González: >> If you or anyone else find any problem, please report a bug; otherwise >> I'll merge to 5.3 and 5.4 once 5.4 is out of code freeze. >> > As it's a security patch and of small scope, I would consider it for > 5.4. Stas, David? as it is SECURITY rele

Re: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds

Am 02.02.2012 19:42, schrieb Tomas Kuliavas: > 2012.02.02 19:42 Reindl Harald rašė: >> security is THE benefit for ALL users, especially in days where many >> are running crap-code like Joomla/Wordpress with all sorts of plugins >> throwing millions of warning if you run wi

Re: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds

Am 02.02.2012 19:02, schrieb Stas Malyshev: > Hi! > >> with many hundret active sessions was not a >> single performance problem > > I'm not sure I understand what you are talking about here. Performance is a > scale, > not a trigger. If you lose 10% (totally invented number as an example) th

Re: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds

Am 02.02.2012 18:37, schrieb Stas Malyshev: >> yes, but suhosin-extension and hardening patch exists since many years >> >> the question from a normal user: >> why are these things not included in the core? > > Because some of these things slow down the code we are using suhosin patch and exte

Re: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds

Am 02.02.2012 14:38, schrieb Pierre Joye: > About the current flaw affecting 5.3/4, PHP and suhosin had bugs, and > will have bugs. This is not really hot news. That does not affect this > discussion. > > I, for one, like the idea to finally see distros droping Suhosin and > focus on making PHP it

Re: [PHP-DEV] FD_SETSIZE warning?

Am 13.01.2012 17:36, schrieb Rasmus Lerdorf: > FD_SETSIZE is a system limit on the number of open files a single > process can have. From a bash shell type: ulimit -n > and you will probably see this magical 1024 number pop up. This means > that the default is 1024 on your system, so raising it in

Re: [PHP-DEV] Re: another fix for max_input_vars.

Am 04.01.2012 21:07, schrieb Paul Dragoonis: > I agree with Rasmus here. A lot of people keep display_errors on, even > when they shouldn't. it is not the job of a programming language stop admins from beeing stupid - the defaults have to be sane and this is display_error OFF, if somebody decid

Re: [PHP-DEV] Re: another fix for max_input_vars.

Am 04.01.2012 21:02, schrieb Rasmus Lerdorf: > But there is a very valid security concern here. People can usually run > safely with display_errors enabled if their code is well-written. if it is well written there would be nor errors displayed but you miss - in production you MUST NOT dispaly

Re: [PHP-DEV] function ob_gzhandler is missed in 5.4

Am 13.11.2011 16:47, schrieb Ferenc Kovacs: > as you can see, there is 2 functions gone in 5.4/trunk: > string(12) "ob_gzhandler" > string(16) "ob_iconv_handler" thank your for confirming that i only liked to get sure what happens early enough the two missing are not soo bad but AFAIK a

Re: [PHP-DEV] function ob_gzhandler is missed in 5.4

Am 13.11.2011 16:11, schrieb Laruence: > Hi: > > this revisioin remove the ob_* functions: > http://svn.php.net/viewvc?view=revision&revision=299980 > > is this intentional? if yes, I think this will become a doc problem i think / hope this is an accident if the ob_functions(9 are replaced i

Re: [PHP-DEV] Changed behaviour of gzencode in PHP-5.4

Am 28.10.2011 10:59, schrieb Michael Wallner: > gzencode in PHP-5.4 behaves differently than in previous versions. > I outlined the reasoning in the comment from 2009-03-03 22:11 UTC > at http://bugs.php.net/47178 as long gzdecode() can decode stored data from previous versions without destroy t

Re: [PHP-DEV] Re: [php-maint] [PHP-DEV] PHP 5.3.9 and is_a changes

Am 25.10.2011 00:18, schrieb de...@lucato.it: > As a user, I would really encourage to include the latest stable 5.x and > provide to the community all the available 5.x upgrade during the next 5 > years (5.4, 5.5 etc). Those 105 php apps should be maintained or removed, > not used as an excuse to

Re: [PHP-DEV] PHP 5.3.9 and is_a changes

Am 22.10.2011 17:36, schrieb Lester Caine: > Johannes Schlüter wrote: There is also a lot to be said for going with what is known to be stable for > > an LTS release. >>> > >>> > Please do not begin with this discussion again. It is confusing for >>> > the readers and totally

Re: [PHP-DEV] Benchmarking ...

Am 21.10.2011 13:00, schrieb Lester Caine: > So I suppose the question I have to ask is what the f**k am I doing wrong on > the windows setup? > I've always known that linux was faster, but 4 times faster on the same > hardware? My main development > machine is giving 27.750 seconds which is

Re: [PHP-DEV] GD Lib for PHP?

Am 02.10.2011 19:16, schrieb sean finney: > On Sun, Oct 02, 2011 at 05:56:10PM +0200, Reindl Harald wrote: >> distributions normally use their libraries for compiling software >> and never static bits - but debian is known to have way too old >> libraries most of the time

Re: [PHP-DEV] GD Lib for PHP?

Am 02.10.2011 17:28, schrieb Lars Nielsen: > Thanks Pierre, > > I have been using GD with Drupal and with the standard gd of either php > or debian/ubuntu Drupal is complaining that GD is not functional. > > So I just have to compile and install the version from bitbucket? no - complain to deb

Re: [PHP-DEV] open_basedir bypass -> errata tempnam()

Am 28.09.2011 17:03, schrieb Ferenc Kovacs: >> please configure the mailing-list correct >> please add a hint that modern clients have a "reply-to-list" > > for the record, I don't have that in gmail. > >> please add a hint that the sender should be removed after >> reply-all because "internals

Re: [PHP-DEV] open_basedir bypass -> errata tempnam()

Am 28.09.2011 16:19, schrieb Hannes Magnusson: > On Wed, Sep 28, 2011 at 00:39, Reindl Harald wrote: >> PLEASE REPLY ONLY TO THE LIST > > PLEASE READ THE POSTING GUIDELINES BEFORE SCREAMING: > http://se.php.net/mailing-lists.php please configure the mailing-list correct plea

Re: [PHP-DEV] open_basedir bypass -> errata tempnam()

Am 28.09.2011 10:53, schrieb Pierre Joye: On Wed, Sep 28, 2011 at 10:50 AM, Reindl Harald wrote: > without any param /tmp is right but not as magical fallback and in > my opinion a well desigend webapp should never touch global /tmp > shared with other hosts and applications Wel

Re: [PHP-DEV] open_basedir bypass -> errata tempnam()

Am 28.09.2011 10:46, schrieb Pierre Joye: > hi, > > On Wed, Sep 28, 2011 at 9:02 AM, Reindl Harald wrote: > > First, all you need to test is: > > $tempfile = tempnam($temp_folder, 'rhcsv'); > $fp = fopen($tempfile , 'w'); > >> * /tmp MUS

Re: [PHP-DEV] open_basedir bypass -> errata tempnam()

Am 28.09.2011 09:28, schrieb Pierre Joye: > On Wed, Sep 28, 2011 at 9:02 AM, Reindl Harald wrote: > >> $tmp_name = str_replace("\\", '/', tempnam($temp_folder, 'rhcsv')); > > Side note: this is never necessary, php does it for you. Unless you

Re: [PHP-DEV] open_basedir bypass -> errata tempnam()

Am 28.09.2011 08:01, schrieb Antony Dovgal: > On 09/28/2011 02:39 AM, Reindl Harald wrote: >> PLEASE REPLY ONLY TO THE LIST > > Please provide a short (10 lines max) but complete reproduce script. > At the moment your explanations do not make any sense. what do you think was

Re: [PHP-DEV] open_basedir bypass -> errata tempnam()

Am 28.09.2011 00:34, schrieb Ángel González: > Reindl Harald schrieb: >> [root@arrakis:~]$ stat /tmp/rhcsvz8QeBL >> File: „/tmp/rhcsvz8QeBL“ >>> Are you sure it is the fopen() what is making it? >>> I think that some other function/extension may be creating

Re: [PHP-DEV] open_basedir bypass -> errata tempnam()

Am 28.09.2011 00:16, schrieb Ángel González: > Reindl Harald wrote: >> below a correct open_basedir restriction >> >> but why can fopen() create this file outside the >> basedir and after that the restriction is active? >> >> this means in other words: fope

[PHP-DEV] open_basedir bypass

below a correct open_basedir restriction but why can fopen() create this file outside the basedir and after that the restriction is active? this means in other words: fopen() can empty files outside the basedir if their permissions are open enough Sep 27 10:53:26 open_basedir restriction in effe

Re: [PHP-DEV] __constructor parameter limitations.

as far as producing a fatal error - though E_STRICT would be OK here -- Mit besten Grüßen, Reindl Harald the lounge interactive design GmbH A-1060 Vienna, Hofmühlgasse 17 CTO / software-development / cms-solutions p: +43 (1) 595 3999 33, m: +43 (676) 40 221 40 icq: 154546673, http://w

Re: [PHP-DEV] __constructor parameter limitations.

Am 19.09.2011 03:00, schrieb Stas Malyshev: > The example without abstract works, but produces E_STRICT which is useless too right - because the following code is totally valid and reasonable even if "my_function" will later get a fourth param $d='default' and the strict warnings here forcing y

Re: [PHP-DEV] __constructor parameter limitations.

Am 17.09.2011 20:08, schrieb Stas Malyshev: > Hi! > >> On Sat, Sep 17, 2011 at 17:08, Laruence wrote: class A { public function init($a, $b) { } } class B extends A { public function init($a) { } } => PHP Strict Standards: Declaration of B::init() should be compa

Re: [PHP-DEV] proposal for change the argument of parse_str/mb_parse_str

Am 11.09.2011 06:31, schrieb Rui Hirokawa: > Hello, > > I think the second argument of parse_str/mb_parse_str > should be changed from optional to mandatory. > parse_str(string encoded_string [, array result]) > -> parse_str(string encoded_string , array result) no because there is no reason an

Re: [PHP-DEV] Make mysqlnd default over libmysql in 5.4

Am 05.09.2011 11:08, schrieb Stas Malyshev: > Hi! > > On 9/5/11 1:24 AM, Andrey Hristov wrote: >> the problem is that libmysql breaks, maybe more often than mysqlnd does. >> We rarely find bugs in mysqli, there are two codepaths in mysqli. If >> there is a bug in libmysql, what do you want: > >

Re: [PHP-DEV] Make mysqlnd default over libmysql in 5.4

Am 04.09.2011 19:52, schrieb Stas Malyshev: >> There are incimoatibilities too across libmysql versions and across >> mysql servers, which are actually affecting existing codes. > > I don't know of any incompatibilities that change semantics on this level, > and anyway libmysql is beyond our c

Re: [PHP-DEV] Make mysqlnd default over libmysql in 5.4

Am 04.09.2011 12:22, schrieb Stas Malyshev: > Hi! > > On 9/4/11 2:38 AM, Pierre Joye wrote: >> What are you actually afraid of? > > Having two different semantics inside one mysql extension. so these have to be cleaned up >> Libmysql will still be supported. Mysqlnd, despite your examples, wo

Re: [PHP-DEV] Make mysqlnd default over libmysql in 5.4

Am 04.09.2011 11:54, schrieb Tomas Kuliavas: > 2011.09.04 12:13 Reindl Harald rašė: >> >> >> Am 04.09.2011 06:37, schrieb Stas Malyshev: >>> Hi! >>> >>> On 9/2/11 6:51 PM, Rasmus Lerdorf wrote: >>>> Forget the failed tests. A new PHP

Re: [PHP-DEV] Make mysqlnd default over libmysql in 5.4

Am 04.09.2011 11:33, schrieb Stas Malyshev: > Hi! > > On 9/4/11 2:13 AM, Reindl Harald wrote: >> again: >> running some hundret domains and made the switch to PHP 5.3 AND mysqlnd >> at once, no single problem - there are no differences in the real world > >

Re: [PHP-DEV] Make mysqlnd default over libmysql in 5.4

Am 04.09.2011 06:37, schrieb Stas Malyshev: > Hi! > > On 9/2/11 6:51 PM, Rasmus Lerdorf wrote: >> Forget the failed tests. A new PHP release is about improving the >> ecosystem. If the folks that maintain libmysql and mysqlnd suggest that >> mysqlnd is more robust and it is the path forward, why

Re: [PHP-DEV] Why does mysqlnd get included in Linux 'core' PHP5 packages?

Am 03.09.2011 17:19, schrieb Lester Caine: > Adding a separate .ini for each package makes a lot more sense this is usally done since years > and all of the extension specific settings can be kept in the one place. You > can then load > a database driver along with all it's own configuration s

Re: [PHP-DEV] Why does mysqlnd get included in Linux 'core' PHP5 packages?

Am 03.09.2011 14:00, schrieb Lester Caine: > Current state of play, the SUSE install includes mysqlnd with the core > package, and mysql and mysqli are available > as extra packages. Again - nowdays the 'required' dependency on MySQL does > seem to have been dropped, but other PHP > extensions

Re: [PHP-DEV] Make mysqlnd default over libmysql in 5.4

Am 03.09.2011 03:08, schrieb Stas Malyshev: > Hi! > > On 9/2/11 6:02 PM, Rasmus Lerdorf wrote: >> Well, we are not trying to get to 0 failed tests in all permutations of >> all extensions on all platforms. We are trying to get to 0 failed tests >> on a common-case build using defaults and common

Re: [PHP-DEV] Make mysqlnd default over libmysql in 5.4

please do it we are using mysqlnd on some hundret domains with all sort of php-software since PHP 5.3.3 (the first 5.3 version we used) and thinking back how hard it was to get the fedora-srpm chnaged to build with mysqlnd my opinion is drop the libmysql-support completly you named the main-reaso

Re: [PHP-DEV] Re: drop bison 1.x?

it seems fedora had never bison 1.x http://koji.fedoraproject.org/koji/packageinfo?packageID=1084 Am 02.09.2011 01:23, schrieb Pierre Joye: > It would be nice to get at least a little bit of the context before going in > any kind of arguing. > > For one the failing test happening after my commit

Re: [PHP-DEV] Cannot build ext/intl on Fedora 15

Am 28.08.2011 10:12, schrieb Sebastian Bergmann: > Am 28.08.2011 10:00, schrieb Stas Malyshev: >> Judging from a quick search this is caused by libstdc++ missing from link >> line, and can be fixed by adding it, but I have no idea what's special >> with new Fedora (i.e., I think some new gcc stuf

Re: [PHP-DEV] ext_skel on Fedora

Am 27.08.2011 02:09, schrieb Aaron Gray: > I cannot seem to find 'ext_skel' or 'PECL_Gen' on my F11 instillation of > php-devel? Fedora 11 is EOL since a bunch of releases time and has PHP 5.2.x 5.2.x is EOL too - consider update your systems from time to time signature.asc Description: Open

Re: [PHP-DEV] PHP 5.3.8 Released!

Am 24.08.2011 10:06, schrieb Sebastian Bergmann: > On 08/24/2011 03:57 AM, a...@akbkhome.com wrote: >> It might have been better to have waited for the is_a() fix to get sorted >> out. > > No, it would have been better if the only difference between PHP 5.3.7 > and PHP 5.3.8 would have been th

Re: [PHP-DEV] 5.3.7 is breaking SSL

Am 23.08.2011 19:21, schrieb Scott MacVicar: > On Aug 17, 2011, at 5:50 PM, Reindl Harald wrote: > >> well i guess it is the change below this results in connections in hanging >> around and after a hughe timeout filling my mailbox with cron-mails: >> >> mysqlnd 5.

Re: [PHP-DEV] Failing Autotests / Bugs

Am 22.08.2011 13:08, schrieb Lester Caine: > Reindl Harald wrote: >> there should be placed diff-files for security fixes directly on the >> download-page >> they could be easily included in rpmbuild/spec-file if they are matching to >> the latest >> tar.bz2

Re: [PHP-DEV] Failing Autotests / Bugs

Am 22.08.2011 11:33, schrieb Lester Caine: > Pierre Joye wrote: >> but does it work with 5.3.6? On the servers where 5.3.7 fails? > > While switching back should simply be a matter of telling the package manager > to use the older version with full disclosed security-bugs they are open and kno

Re: [PHP-DEV] Failing Autotests / Bugs

0:31, schrieb Pierre Joye: > but does it work with 5.3.6? On the servers where 5.3.7 fails? > > On Mon, Aug 22, 2011 at 10:26 AM, Reindl Harald > wrote: >> i can not easily replace files because rpmbuild does >> unpack and patch the source automated and some patches >> are

Re: [PHP-DEV] Failing Autotests / Bugs

> means that the fix applied in 5.3.7 actually works with server >> versions but not other. >> >> However we can't take a decision without their agreement (no revert if >> they don't do it themselves or if they don't ask us to do it). >> >> C

Re: [PHP-DEV] Failing Autotests / Bugs

ith some versions. It happened already a lot in the past (be > the server or the libmysql). > > On Sun, Aug 21, 2011 at 8:46 PM, Reindl Harald wrote: >> hardly to understand because the mysql-server is unchanged >> mysql 5.5.15 and before 5.3.7 there was no problem for >> ov

Re: [PHP-DEV] Failing Autotests / Bugs

> they don't do it themselves or if they don't ask us to do it). > > Cheers, > > On Sun, Aug 21, 2011 at 3:26 PM, Reindl Harald wrote: >> hi >> >> it was surely not present in mysqlnd before because we are running a bundle >> of servers which

  1   2   3   >