Re: [PHP-DEV] RFC: execution opcode file without php source code file

On Fri, Oct 2, 2020 at 10:08 AM David Rodrigues wrote: > > Hello folks, > > Instead of an opcode without a php source file, that I imagine is to > protect the code itself, why not a method to encrypt phar files (not like a > password). I do not know if exists a secure method to decrypt to execute

Re: [PHP-DEV] T_PAAMAYIM_NEKUDOTAYIM is terrible, are we sure we're OK with it?

We read phil's post years ago (it is from 2013). Do you have anything new to contribute to the discourse other than posting a link to a post from 7 years ago? If so, you should present that and not old web pages . Walter On Tue, Jul 28, 2020 at 7:31 PM Ryan Jentzsch wrote: > >

Re: [PHP-DEV][RFC] Rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON

On Wed, Jun 10, 2020 at 3:14 PM Sara Golemon wrote: > On Wed, Jun 10, 2020 at 3:33 PM Ryan Jentzsch > wrote: > > > OMG the trolling continues even today with this nonsense. Disappointing. > > > > Oh yes. And histrionics will certainly deescalate that issue. > > > > "...yes, it is broken, people

Re: [PHP-DEV] Internals "camps"

Sure, sorry about that. I'm done with the silliness as we at an impasse. Walter On Fri, Oct 11, 2019 at 10:45 AM Larry Garfield wrote: > > On Fri, Oct 11, 2019, at 1:53 AM, Stephen Reay wrote: > > > > > > > On 11 Oct 2019, at 13:42, Walter Parker wrote: > > &

Re: [PHP-DEV] Internals "camps"

On Thu, Oct 10, 2019 at 11:11 PM Stephen Reay wrote: > > > > On 11 Oct 2019, at 12:40, Walter Parker wrote: > > > > G > > > > On Thu, Oct 10, 2019 at 10:10 PM Stephen Reay > > wrote: > > > >> > >> > >>> On 11 Oct 2

Re: [PHP-DEV] Internals "camps"

G On Thu, Oct 10, 2019 at 10:10 PM Stephen Reay wrote: > > > > On 11 Oct 2019, at 02:59, Walter Parker wrote: > > > > On Thu, Oct 10, 2019 at 10:36 AM Chase Peeler > wrote: > > > >> > >> > >> On Thu, Oct 10, 2019 at 1:30 PM Walter P

Re: [PHP-DEV] Internals "camps"

On Thu, Oct 10, 2019 at 3:27 PM Mark Randall wrote: > On 10/10/2019 23:04, Walter Parker wrote: > > If this truly is the problem that you say it is, there should be plenty > of > > documentation online as to the issues that it has cause. Maybe you could > > post

Re: [PHP-DEV] Internals "camps"

On Thu, Oct 10, 2019 at 1:27 PM Mark Randall wrote: > On 10/10/2019 20:59, Walter Parker wrote: > > They will either be stuck on an old version of PHP or have to pay to > update the code. > > If you're getting stuck on a island after being given 4 or 5 years > wa

Re: [PHP-DEV] Internals "camps"

On Thu, Oct 10, 2019 at 11:04 AM Mark Randall wrote: > On 10/10/2019 18:30, Walter Parker wrote: > > "Ferry" projects might be: more/better training on PHP, better > > documentation so that the backtick is no longer an "obscure" feature to > > those tha

Re: [PHP-DEV] Internals "camps"

On Thu, Oct 10, 2019 at 10:36 AM Chase Peeler wrote: > > > On Thu, Oct 10, 2019 at 1:30 PM Walter Parker wrote: > >> > >> > >> > No. The compromise is funding a ferry system. Or laying Internet between >> > them. Or a passenger pigeon mail rou

Re: [PHP-DEV] Internals "camps"

> > > No. The compromise is funding a ferry system. Or laying Internet between > them. Or a passenger pigeon mail route. > > Sometimes compromise requires deep discussion about the motivations for > each side and coming to a lateral, mutually acceptable, solution. > > But we'd rather not discuss

Re: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)

On Tue, Oct 8, 2019 at 2:25 PM M. W. Moe wrote: > Hello, > > what you write and advocate for can't be heard by a vast majority of people > here; because they are just not North-American; somehow > that's a very interesting trait; most of people despise `kind` moralism. > > > On Tue, Oct 8, 2019

Re: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)

On Tue, Oct 8, 2019 at 1:23 PM M. W. Moe wrote: > @Mike Schinkel, > > a middle ground about/with silliness? there is none, for people in their > right mind; should people really find/force > themselves into conciliation about non-sense? I don't think so and mostly; > I have no say about

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

On Tue, Aug 6, 2019 at 2:55 PM Claude Pache wrote: > > > > Le 6 août 2019 à 20:46, Nikita Popov a écrit : > > > > On Tue, Aug 6, 2019 at 1:34 PM G. P. B. > wrote: > > > >> The voting for the "Deprecate short open tags, again" [1] RFC has begun. > >> It is expected to last two (2) weeks until

Re: [PHP-DEV][DISCUSSION] Multilingual PHP

I also am old enough to have used/remember using BASIC. I remember German and Japanese friends that wrote in BASIC. It was interesting to see German programs where all the keywords were in English and all the text was in German. The Japanese was even more strange as the system had to switch

Re: [PHP-DEV] phpenmod/phpdismod

On Sat, Feb 2, 2019 at 1:06 PM Peter Kokot wrote: > >> 3. Do you know where is the source code of these two scripts? When the > >> upstream script gets updated it would be then useful to copy/paste > >> changes into php-src. So the main development should be happening > >> upstream anyway.

Re: [PHP-DEV] Unifying logical operators

On Tue, Jul 10, 2018 at 7:58 PM, Alice Wonder wrote: > On 07/10/2018 07:20 PM, Ryan wrote: > >> On Tue, Jul 10, 2018 at 2:26 AM, Walter Parker wrote: >> >> >>> That is a matter of style, as I find $a = func() or die more clear that >>> the versi

Re: [PHP-DEV] Unifying logical operators

On Mon, Jul 9, 2018 at 9:03 PM Ryan wrote: > Hello all! Longtime PHP user, first-time contributor to internals (sorry > if I screw anything up)! > > I'd like to propose either the deprecation (7.next - likely 7.4 at this > point) and removal (8.0) of the T_LOGICAL_OR (or), T_LOGICAL_AND (and),

Re: [PHP-DEV] PHP 7.2.0 Released

Deleted without reading... On Tue, Dec 5, 2017 at 9:09 AM, li...@rhsoft.net <li...@rhsoft.net> wrote: > > > Am 05.12.2017 um 17:45 schrieb Walter Parker: > >> Lists, I give you the same advice. I know and use SSL Labs, I been a >> subscriber to Ivan's mailing

Re: [PHP-DEV] PHP 7.2.0 Released

On Tue, Dec 5, 2017 at 12:54 AM, li...@rhsoft.net <li...@rhsoft.net> wrote: > > > Am 05.12.2017 um 06:52 schrieb Walter Parker: > >> On Mon, Dec 4, 2017 at 6:27 PM, li...@rhsoft.net <mailto:li...@rhsoft.net> >> <li...@rhsoft.net <mailto:li...@rhsoft.net

Re: [PHP-DEV] PHP 7.2.0 Released

On Mon, Dec 4, 2017 at 6:27 PM, li...@rhsoft.net <li...@rhsoft.net> wrote: > > > Am 05.12.2017 um 01:19 schrieb Walter Parker: > >> Oh, I see, this not about the actual change (the protocol version). This >> is about when using PHP on the client side,

Re: [PHP-DEV] PHP 7.2.0 Released

On Mon, Dec 4, 2017 at 2:21 PM, li...@rhsoft.net <li...@rhsoft.net> wrote: > > > Am 04.12.2017 um 22:53 schrieb Walter Parker: > >> On Mon, Dec 4, 2017 at 1:43 PM, Niklas Keller <m...@kelunik.com> wrote: >> >>> and to be clear here: >>>>

Re: [PHP-DEV] PHP 7.2.0 Released

On Mon, Dec 4, 2017 at 1:43 PM, Niklas Keller wrote: > > > > and to be clear here: > > > > a client when connecting to a server configured like below has to respect > > the cipher order of the server while > > https://www.ssllabs.com/ssltest/ exists for years to give

Re: [PHP-DEV] PHP 7.2.0 Released

On Fri, Dec 1, 2017 at 3:35 PM, li...@rhsoft.net wrote: > > > Am 01.12.2017 um 22:49 schrieb Sara Golemon: > >> On Fri, Dec 1, 2017 at 11:52 AM, li...@rhsoft.net >> wrote: >> >>> yes and since nobody ever sould override the defaults in application code >>>

Re: [PHP-DEV] RFC proposal: Provide support for XSLT 3.0, XPath 3.1, and XQuery 3.1

On Wed, Oct 4, 2017 at 10:57 AM, Davey Shafik <da...@php.net> wrote: > On Tue, Oct 3, 2017 at 1:29 PM, Walter Parker <walt...@gmail.com> wrote: > >> On Tue, Oct 3, 2017 at 7:51 AM, Dan Ackroyd <dan...@basereality.com> >> wrote: >> >> > Hi O

Re: [PHP-DEV] RFC proposal: Provide support for XSLT 3.0, XPath 3.1, and XQuery 3.1

On Tue, Oct 3, 2017 at 7:51 AM, Dan Ackroyd wrote: > Hi O'Neil, > > On 3 October 2017 at 10:04, O'Neil Delpratt wrote: > > Hi, > > > > We are considering submitting an RFC along the following lines and > welcome your comments: > > > > Enhancing the

Re: [PHP-DEV] array coalesce operator concept

On Thu, Jul 13, 2017 at 2:55 AM, Tony Marston wrote: > "David Rodrigues" wrote in message news:CAEsg9X2ECG62i7Z_Nu11kqr7 > yvbkmucd3mxgt78ulampfx-...@mail.gmail.com... > >> >> The idea is good, but I don't know if it is more clear than an 'if()' >> > > I think that this

Re: [PHP-DEV] Directory separators on Windows

On Thu, Mar 30, 2017 at 8:21 AM, Sara Golemon wrote: > My first thought is UNC paths. On windows a file server share is > denoted by \\host\share . if you combine that with relative paths > produced from PHP, you end up in the dubious situation of > "\\host\share/path/to/file"

Re: [PHP-DEV] Re: Not autoloading functions

On Thu, Jan 26, 2017 at 12:23 PM, Rasmus Schultz wrote: > > if you choose to use static methods instead of functions > > It's not a choice - functions are practically useless in a Composer > context, and most everything PHP is now Composer packages. > > Why are functions

[PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle

> > It is NOT insulting to say that people who still insist on using command > line tools are living in the past for the simple reason that the command > line interface was replaced with the GUI when the Windows OS was released > in the 1990s. That is 25 years ago. Is that in the past or what?

Re: [PHP-DEV] Re: [PHP] feature request : gzip caching

On Sat, Aug 27, 2016 at 7:56 PM, Rene Veerman < rene.veerman.netherla...@gmail.com> wrote: > noted, and sorry about confusing it, but can we rest this discussion here? > i dont wanna clog up the thread any further.. > > > Before you go, two observations: First, your website doesn't actually

Re: [PHP-DEV] New escaped output operator

999% > cases. > > 2016-06-20 4:41 GMT+05:00 Walter Parker <walt...@gmail.com>: > >> >>> >>> > where getting it 90% correct is worse that not doing anything at all. >>> > Things like this will cause people to be blindsided when the uncaught &

Re: [PHP-DEV] New escaped output operator

> > > > > where getting it 90% correct is worse that not doing anything at all. > > Things like this will cause people to be blindsided when the uncaught > escapes > > cause the next major security problem. > > Why do you think so? What real problems can happen if there will be a > short operator

Re: [PHP-DEV] New escaped output operator

>From your story Scott, it looks like the failure was bad input filtering, not input filtering in general. If sites are really trying to be secure, they should follow both Lester's and your ideas and filter on input and escape on output. Given your second link the better suggestion is to stop

Re: [PHP-DEV] New escaped output operator

Thomas, are you actually reading and understanding what the others are saying? You seem to be answering questions that have not been asked or giving the simple, easy and wrong answer. Walter On Fri, Jun 17, 2016 at 1:37 PM, Thomas Bley wrote: > using the default encoding

Re: [PHP-DEV] How to get trace of all database queries executed by php

On Fri, May 6, 2016 at 4:34 PM, Raja Kulasekaran wrote: > Hi, > > Sorry If I am asking this question in irrelevent forum. > Please suggest me the point of direction if not. > > I have encrypted php Application codebase which I may or may not have > access. > > So, I would like

Re: [PHP-DEV] [RFC Discussion] Typed Properties

On Friday, March 18, 2016, Larry Garfield wrote: > On 03/18/2016 03:49 PM, Fleshgrinder wrote: > >> First a general note on the complete nullability first: It is not up to >> us as language designers to decide whether it is good practice to use >> nullable properties or

Re: [PHP-DEV] [RFC Proposal] var keyword deprecation/removal

> > > That we should definitely avoid. I do not consider the *var* keyword > being a discussion about coding style preferences---this decision was > already made in PHP 5! The *public* keyword was introduced and it > superseded the *var* keyword including an E_STRICT error. Hence, this >

Re: [PHP-DEV] [RFC Proposal] var keyword deprecation/removal

On Mon, Mar 7, 2016 at 4:27 AM, wrote: > > Change for the sake of change is bad, no argument there. Change for the > > > sake of progress is not and totally normal. > > > > Can you please specify what kind of progress do see in the `var` keyword > removal? I see only a BC

Re: [PHP-DEV] [RFC Proposal] var keyword deprecation/removal

On Sat, Mar 5, 2016 at 7:00 AM, Fleshgrinder wrote: > On 3/5/2016 2:33 PM, Lester Caine wrote: > > On 05/03/16 11:26, Fleshgrinder wrote: > >> PHP being a mess is still one of the most quoted arguments against PHP! > >> > Only if it results in an actual and measurable

Re: [PHP-DEV] [RFC Proposal] var keyword deprecation/removal

On Fri, Feb 19, 2016 at 1:10 AM, Tony Marston <tonymars...@hotmail.com> wrote: > "Walter Parker" wrote in message > news:CAMPTd_AHyV2d0_Saq=kpvhdzkkcmgkxav8tnt4hk9sdngkc...@mail.gmail.com... > >> >> On Thu, Feb 18, 2016 at 11:30 AM, Sebastian Bergmann <seb

Re: [PHP-DEV] [RFC Proposal] var keyword deprecation/removal

On Thu, Feb 18, 2016 at 11:30 AM, Sebastian Bergmann wrote: > On 02/18/2016 02:10 PM, Colin O'Dell wrote: > >> I'd like to propose an RFC to deprecate and eventually remove the "var" >> keyword. >> > > +1 > > -- > PHP Internals - PHP Runtime Development Mailing List > To

Re: [PHP-DEV] is_digits() and digits type

and validations can cause problems. I don't see how adding pseudo types will actually fix this as this appears to a validation problem and not a typing problem. On Thu, May 14, 2015 at 12:16 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi Walter, On Tue, May 12, 2015 at 11:25 AM, Walter Parker walt

Re: [PHP-DEV] is_digits() and digits type

, May 15, 2015 at 2:49 AM, Walter Parker walt...@gmail.com wrote: Adding a numeric pseudo type will not fix abuse, it will only change the abuse. I don't think it is worth the effort. I also think it might a slippery slope to lots of other pseudo types and other half ideas that will add

Re: [PHP-DEV] is_digits() and digits type

On Tue, May 12, 2015 at 12:27 PM, Lester Caine les...@lsces.co.uk wrote: On 12/05/15 19:55, Rowan Collins wrote: For instance, valid input for a 64-bit signed integer in a database could include: - any PHP native integer (assuming nobody builds with 128-bit ints!) - any string consisting

Re: [PHP-DEV] is_digits() and digits type

You know, given how worried you seem to be about this issue, could you booby trap your so that if the developers use the wrong type (int vs. string) the program throws fatal errors with nasty error messages that explain how much trouble the developer is in at the userland code level? While I like

Re: [PHP-DEV] Adding numeric type hint

On Wed, Apr 29, 2015 at 11:40 PM, Arvids Godjuks arvids.godj...@gmail.com wrote: Stop trying to fix clever idiots from shooting themselves in the foot. The standard result from these actions is to make life a pain for regular or better programmers while only adding mild speed bumps to those

Re: [PHP-DEV] Adding numeric type hint

On Wed, Apr 29, 2015 at 11:54 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi Arvids, On Thu, Apr 30, 2015 at 3:40 PM, Arvids Godjuks arvids.godj...@gmail.com wrote: Stop trying to fix clever idiots from shooting themselves in the foot. The standard result from these actions is to make life

Re: [PHP-DEV] Adding numeric type hint

On Wed, Apr 29, 2015 at 11:47 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi Walter, On Thu, Apr 30, 2015 at 3:12 PM, Walter Parker walt...@gmail.com wrote: And that is relevant how? How many Android phone run PHP applications? Search web for IoT devices that can run PHP. Regards

Re: [PHP-DEV] Adding numeric type hint

On Thu, Apr 30, 2015 at 12:06 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi Walter, On Thu, Apr 30, 2015 at 3:54 PM, Walter Parker walt...@gmail.com wrote: You didn't answer the question: why should we care? Is there enough of user base now to care? IOT might be able to run PHP, but how

Re: [PHP-DEV] Adding numeric type hint

On Thu, Apr 30, 2015 at 7:35 AM, Levi Morrison le...@php.net wrote: This numeric type is a type of int or float. There is a formal name for such types: union types. Some languages have syntax for union types that would look like this: int | float. I have a draft RFC for this subject:

Re: [PHP-DEV] Adding numeric type hint

On Wed, Apr 29, 2015 at 10:42 PM, Stanislav Malyshev smalys...@gmail.com wrote: Hi! int Cast is bad. Incorrect int type hint worse as it could trigger DoS. I do not see any potential for DoS here. Trying to assign security implications so it looks like disagreeing with you jeopardizes

Re: [PHP-DEV] Adding numeric type hint

On Wed, Apr 29, 2015 at 10:50 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Ryan, On Thu, Apr 30, 2015 at 1:29 PM, Ryan Pallas derokor...@gmail.com wrote: On Wed, Apr 29, 2015 at 8:37 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi Rowan, On Thu, Apr 30, 2015 at 11:17 AM, Yasuo Ohgaki

Re: [PHP-DEV] Adding numeric type hint

On Wed, Apr 29, 2015 at 7:37 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi Rowan, On Thu, Apr 30, 2015 at 11:17 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: A fatal error wouldn't constitute a DoS vulnerability, would it? Attacker may inject huge ID value and/or they may simply access

Re: [PHP-DEV] Adding numeric type hint

On Wed, Apr 29, 2015 at 9:33 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi Walter, On Thu, Apr 30, 2015 at 11:52 AM, Walter Parker walt...@gmail.com wrote: Are you asking to have both the 32 and 64 bit versions of PHP fully map to the type system in SQLite? The type system in SQLite appears

[PHP-DEV] Removing from git history

From: Pierre Schmitz pie...@archlinux.de To: internals@lists.php.net Cc: Date: Sat, 25 May 2013 05:48:07 +0200 Subject: Re: [PHP-DEV] Re: About fileinfo test.mp3 Am 24.05.2013 23:38, schrieb Anatol Belski: Hi David, On Fri, 2013-05-24 at 23:28 +0200, David Soria Parra wrote: Hi Anatol, I saw