Derick Rethans wrote:
On Tue, 15 Nov 2005, Rasmus Lerdorf wrote:
Derick Rethans wrote:
On Tue, 15 Nov 2005, Andrei Zmievski wrote:
Perhaps, but I would maintain that passing "123abc" and having it
interpreted
as 123 is still wrong.
Yeah, I lean that way too, although trailing whitespace sho
On Tue, 15 Nov 2005, Rasmus Lerdorf wrote:
> Derick Rethans wrote:
> > On Tue, 15 Nov 2005, Andrei Zmievski wrote:
> >
> > > Perhaps, but I would maintain that passing "123abc" and having it
> > > interpreted
> > > as 123 is still wrong.
> >
> > Yeah, I lean that way too, although trailing white
Derick Rethans wrote:
On Tue, 15 Nov 2005, Andrei Zmievski wrote:
Perhaps, but I would maintain that passing "123abc" and having it interpreted
as 123 is still wrong.
Yeah, I lean that way too, although trailing whitespace should be
supported IMO.
I don't like having two different ways to
On Tue, 15 Nov 2005, Andrei Zmievski wrote:
> Perhaps, but I would maintain that passing "123abc" and having it interpreted
> as 123 is still wrong.
Yeah, I lean that way too, although trailing whitespace should be
supported IMO.
regards,
Derick
--
Derick Rethans
http://derickrethans.nl | htt
On Tue, 15 Nov 2005, Steph Fox wrote:
> Hopefully I have the PDO stuff outlined a little better now.
>
> I know Dmitry and Derick have both committed changes today that should go in
> here, and await the outcome of the zend_parse_parameters() discussion with
> interest.
>
> Anything else missing
Sara Golemon wrote:
with MD5 and SHA1 more or less broken
Overstatement much?
I've had implementations of sha256,384, and 512 lying about for months now
(possibly over a year), but was told they didn't have a place in core since
mhash provided the functionality (A statement I recall agreeing w
Hello Internals,
Remember the ifsetor() discussion? There were many, many people for
it, and many people that did not see the point. To this day, it's
not been allowed into the source tree, and I don't see any way to
change that. So...
Please consider (some form of) this if it's poss
>I've had implementations of sha256,384, and 512 lying about for months now
>(possibly over a year), but was told they didn't have a place in core since
>mhash provided the functionality (A statement I recall agreeing with at the
>time fwiw). What changed?
>
>
Since a year a lot of things have
Sara Golemon wrote:
> I've had implementations of sha256,384, and 512 lying about for months now
> (possibly over a year), but was told they didn't have a place in core since
> mhash provided the functionality (A statement I recall agreeing with at the
> time fwiw). What changed?
Didn't you hear
Specifically, you want to enable the (under-documented)
runkit.internal_override INI option. It's mentioned on the reference page,
but with no explanation of what it does. I need to make a language-snippet
for that at some point
This was added in version 0.6 (prior versions could only overri
>> with MD5 and SHA1 more or less broken
>>
Overstatement much?
>> I have hacked together sha256() and sha256_file(),
>>
The more the merrier I say...
> There will be another RC, but I'd prefer to reserve
> this feature till PHP 5.1.1.
>
I've had implementations of sha256,384, and 512 lying about
Perhaps, but I would maintain that passing "123abc" and having it
interpreted as 123 is still wrong.
-Andrei
On Nov 15, 2005, at 9:42 AM, Wez Furlong wrote:
I can't think of any case where you'd want to error out when given
'100 ' if it would accept '100' quite happily.
I'd lean towards a
Perhaps, but I would maintain that passing "123abc" and having it
interpreted as 123 is still wrong.
-Andrei
On Nov 15, 2005, at 9:42 AM, Wez Furlong wrote:
I can't think of any case where you'd want to error out when given
'100 ' if it would accept '100' quite happily.
I'd lean towards a
Thanks Lukas, looking.
- Original Message -
From: "Lukas Smith" <[EMAIL PROTECTED]>
To:
Sent: Tuesday, November 15, 2005 8:46 PM
Subject: [PHP-DEV] Re: Upgrade notes for PHP 5.1 - 3rd draft
> Steph Fox wrote:
>
> > Anything else missing?
>
> I have listed a few items here. I havent c
Thanks Wez, consider it done - and sorry I took up so much of your time
today, I know you're busy.
- Original Message -
From: "Wez Furlong" <[EMAIL PROTECTED]>
To: "Steph Fox" <[EMAIL PROTECTED]>
Cc: "internals"
Sent: Tuesday, November 15, 2005 7:25 PM
Subject: Re: [PHP-DEV] Upgrade note
I think runkit is what you're looking for.
http://pecl.php.net/packages/runkit
--Wez.
On 11/15/05, Alan Cox <[EMAIL PROTECTED]> wrote:
> Hello -
> Is there a way to build an extension that overrides the default
> behavior of a built-in PHP function? Would it be possible to add an
> extension t
Stefan,
There will be another RC, but I'd prefer to reserve this feature till
PHP 5.1.1.
Ilia
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hello -
Is there a way to build an extension that overrides the default
behavior of a built-in PHP function? Would it be possible to add an
extension that removes a PHP function, so that I could redefine it in my
PHP code?
What I want to do is override the time calculations. We are running
Hello Bob,
Tuesday, November 15, 2005, 11:30:18 PM, you wrote:
> Would objects be included in this "one consistent way to cast things"? The
> old zend_get_parameters API works since the calling function was responsible
> for the conversions, but in the newer zend_parse_parameters API they get
> f
Hello,
with MD5 and SHA1 more or less broken, I have hacked together sha256() and
sha256_file(),
because people want a secure hashing function in plain PHP without the need for
3rd party
libraries like mhash.
Both functions are already available to users of the PHP Hardening-Patch for
quite a
Would objects be included in this "one consistent way to cast things"? The
old zend_get_parameters API works since the calling function was responsible
for the conversions, but in the newer zend_parse_parameters API they get
filtered out by the case statement on what "types" to pass into the
conver
Steph Fox wrote:
Anything else missing?
I have listed a few items here. I havent checked which ones you covered
in your test:
http://oss.backendmedia.com/PhP51
But from a quick glance you may have missed points 4-6
regards,
Lukas
--
PHP Internals - PHP Runtime Development Mailing List
To
Rasmus Lerdorf wrote:
Wez Furlong wrote:
I can't think of any case where you'd want to error out when given
'100 ' if it would accept '100' quite happily.
I'd lean towards a single cast semantic for this, and remove that
strict checking flag from zend_parse_parameters(); lazy dynamic type
hand
Hello Derick,
Tuesday, November 15, 2005, 8:19:28 PM, you wrote:
> On Tue, 15 Nov 2005, Dmitry Stogov wrote:
>> On Tue, 15 Nov 2005, Derick Rethans wrote:
>>
>> > On Tue, 15 Nov 2005, Dmitry Stogov wrote:
>> >
>> > > dmitry Tue Nov 15 11:49:44 2005 EDT
>> > >
>> > > Modified files
"The 'sqlite2' PDO driver supplied
to PDO via the sqlite extension, allows you to access legacy SQLite 2
databases created by external processes or with earlier versions of PHP."
I'd reword this as "The sqlite extension also provides the PDO
'sqlite2' driver, and allows you to access legacy SQLite
On Tue, 15 Nov 2005, Dmitry Stogov wrote:
> On Tue, 15 Nov 2005, Derick Rethans wrote:
>
> > On Tue, 15 Nov 2005, Dmitry Stogov wrote:
> >
> > > dmitry Tue Nov 15 11:49:44 2005 EDT
> > >
> > > Modified files: (Branch: PHP_5_1)
> > > /ZendEngine2zend_compile.c
>
Hopefully I have the PDO stuff outlined a little better now.
I know Dmitry and Derick have both committed changes today that should go in
here, and await the outcome of the zend_parse_parameters() discussion with
interest.
Anything else missing?
- Steph
UPGRADE NOTES - PHP 5.1
1. Changes in ref
I've added outgoing IP selection to fsockopen function.
It's usefull if host has multiple IPs (NICs) to pick specific one instead of
default.
Same functionality is kept if outgoing IP isn't specified.
Patch is against 4.4.1.
Maybe it would be appropriate to include this feature?
php4-fsock.ta
Wez Furlong wrote:
I can't think of any case where you'd want to error out when given
'100 ' if it would accept '100' quite happily.
I'd lean towards a single cast semantic for this, and remove that
strict checking flag from zend_parse_parameters(); lazy dynamic type
handling for primitive data
I can't think of any case where you'd want to error out when given
'100 ' if it would accept '100' quite happily.
I'd lean towards a single cast semantic for this, and remove that
strict checking flag from zend_parse_parameters(); lazy dynamic type
handling for primitive data types is one of the c
On Tue, 15 Nov 2005 09:29:29 -0800
[EMAIL PROTECTED] (Rasmus Lerdorf) wrote:
>> my answer was to Jani's.
>
> I realize that, but Jani said "bad data" not data of the wrong type.
> Your example didn't have any bad data. You just had "100" which is a
> perfectly valid numeric string and will wor
On Tue, 15 Nov 2005, Rasmus Lerdorf wrote:
Jani Taskinen wrote:
On Tue, 15 Nov 2005, Rasmus Lerdorf wrote:
Pierre wrote:
On Tue, 15 Nov 2005 18:59:32 +0200 (EET)
[EMAIL PROTECTED] (Jani Taskinen) wrote:
If you pass bad data to a function, it should not warn you?
I'd rather have
Jani Taskinen wrote:
On Tue, 15 Nov 2005, Rasmus Lerdorf wrote:
Pierre wrote:
On Tue, 15 Nov 2005 18:59:32 +0200 (EET)
[EMAIL PROTECTED] (Jani Taskinen) wrote:
If you pass bad data to a function, it should not warn you?
I'd rather have it as a FATAL error. :)
Nothing to fix
Pierre wrote:
On Tue, 15 Nov 2005 09:17:20 -0800
[EMAIL PROTECTED] (Rasmus Lerdorf) wrote:
Pierre wrote:
On Tue, 15 Nov 2005 18:59:32 +0200 (EET)
[EMAIL PROTECTED] (Jani Taskinen) wrote:
If you pass bad data to a function, it should not warn you?
I'd rather have it as a FATAL error
On Tue, 15 Nov 2005, Rasmus Lerdorf wrote:
Pierre wrote:
On Tue, 15 Nov 2005 18:59:32 +0200 (EET)
[EMAIL PROTECTED] (Jani Taskinen) wrote:
If you pass bad data to a function, it should not warn you?
I'd rather have it as a FATAL error. :)
Nothing to fix here, move along. (and
>I'd also suggest that all the PDO extensions be built shared to
>facilitate easier upgrades via PECL as new features are developed
>there, but that's just me.
:) no it isn't, PDO's cool.
Thanks for all your help over this.
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To uns
I would say something like this:
In PHP 5.0, SQLite 2 support was provided by the sqlite extension.
With the introduction of PDO, the sqlite extension now also provides a
'sqlite2' driver for PDO; this means that the sqlite extension depends
upon the PDO extension.
PHP 5.1 ships with a number of
I think all of us who were upset making the transition to 4.4.0 would greatly
appreciate if (in the future) there will not only be short "there's a new
release" notices, but if these notices would directly point to a list like this
one.
E. g. MySQL does a pretty good job with their upgrade no
On Tue, 15 Nov 2005 09:17:20 -0800
[EMAIL PROTECTED] (Rasmus Lerdorf) wrote:
> Pierre wrote:
> > On Tue, 15 Nov 2005 18:59:32 +0200 (EET)
> > [EMAIL PROTECTED] (Jani Taskinen) wrote:
> >
> >> If you pass bad data to a function, it should not warn you?
> >> I'd rather have it as a FATAL
Pierre wrote:
On Tue, 15 Nov 2005 18:59:32 +0200 (EET)
[EMAIL PROTECTED] (Jani Taskinen) wrote:
If you pass bad data to a function, it should not warn you?
I'd rather have it as a FATAL error. :)
Nothing to fix here, move along. (and fix your code..)
PHP is losely typed, I see
Pierre wrote:
> On Tue, 15 Nov 2005 18:59:32 +0200 (EET)
> [EMAIL PROTECTED] (Jani Taskinen) wrote:
>
>
>> If you pass bad data to a function, it should not warn you?
>> I'd rather have it as a FATAL error. :)
>>
>> Nothing to fix here, move along. (and fix your code..)
>
>
> PHP is
Jani Taskinen wrote:
If you pass bad data to a function, it should not warn you?
I'd rather have it as a FATAL error. :)
Nothing to fix here, move along. (and fix your code..)
The issue here is we effectively have two different casting mechanisms.
One of the things we need to do
On Tue, 15 Nov 2005 18:59:32 +0200 (EET)
[EMAIL PROTECTED] (Jani Taskinen) wrote:
>
> If you pass bad data to a function, it should not warn you?
> I'd rather have it as a FATAL error. :)
>
> Nothing to fix here, move along. (and fix your code..)
PHP is losely typed, I see nothin
Draft 1:
In PHP 5.0, SQLite 2 support was built-in. Due to the advent of SQLite 3
and PHP Data Objects, the SQLite engine is no longer statically built into
PHP by default. The PDO_SQLITE driver communicates with the SQLite 3 engine,
and the sqlite extension remains in place only for reasons of ba
If you pass bad data to a function, it should not warn you?
I'd rather have it as a FATAL error. :)
Nothing to fix here, move along. (and fix your code..)
--Jani
On Tue, 15 Nov 2005, Sean Coates wrote:
I discussed this with Rasmus and Derick, yesterday, but I don't think we
It's up to you to enable/disable it and set the default filtering
mode. But it will be on by default.
--Jani
On Tue, 15 Nov 2005, Matt Asher wrote:
On 15.11.2005 15:06, Roman Ivanov wrote:
This particular extension treats each input variable individually,
which is not desi
I wouldn't "strongly" recommend the use of PDO when upgrading; that's
sending the wrong message. I'd "warmly" recommend that the use of PDO
be considered for new projects.
The sqlite information is wrong. This is the way it is:
ext/sqlite bundles sqlite version 2. The extension provides the "g
> On 15.11.2005 15:06, Roman Ivanov wrote:
>
>> This particular extension treats each input variable individually,
>> which is not desirable in majority of scripts I worked with. Such
>> approach adds unnecessary complexity to the script, and requires to
>> handle each invalid variable separate
I discussed this with Rasmus and Derick, yesterday, but I don't think we
came to a conclusion..
Is this a bug, or intended behaviour?
[EMAIL PROTECTED]:~$ /opt/src/php-5.0.4/sapi/cli/php -r 'echo date("r",
"1132003418 ") ."\n";'
Mon, 14 Nov 2005 16:23:38 -0500
[EMAIL PROTECTED]:~$ /opt/src/php5-2
Hi all,
I've already canvassed Ilia and Stas - can anyone else think of anything
I've missed/mis-explained here?
Thanks guys/guyess,
- Steph
UPGRADE NOTES - PHP 5.1
1. Changes in reference handling
a. Overview
b. Code that worked under PHP 4.3, but now fails
c. Code that was valid u
Michael Wallner wrote:
Hi Roman Ivanov, you wrote:
Sorry, do not have time to simplify. This is how I do it:
function filterRequest($prototype, $action){
loadPrototype($prototype);
$vars = get_class_vars($prototype);
if ($vars['vigilant'] == FALSE) {
return $_REQUEST;
}
Hi Roman Ivanov, you wrote:
> Sorry, do not have time to simplify. This is how I do it:
>
> function filterRequest($prototype, $action){
> loadPrototype($prototype);
> $vars = get_class_vars($prototype);
> if ($vars['vigilant'] == FALSE) {
> return $_REQUEST;
> }
>
>
Antony Dovgal wrote:
On 15.11.2005 15:06, Roman Ivanov wrote:
This particular extension treats each input variable individually,
which is not desirable in majority of scripts I worked with. Such
approach adds unnecessary complexity to the script, and requires to
handle each invalid variable s
On 15.11.2005 15:06, Roman Ivanov wrote:
This particular extension treats each input variable individually, which
is not desirable in majority of scripts I worked with. Such approach
adds unnecessary complexity to the script, and requires to handle each
invalid variable separately as well. But
Antony Dovgal wrote:
> Obviously, no, this won't be the only way to get the data.
That's good.
Honestly, I'm not so sure it's a good idea to implement it like PECL
extension does. Filtering individual variables is, in my opinion, a
wrong way to treat user input.
>>>
>>> You may fi
On 15.11.2005 05:38, Roman Ivanov wrote:
Antony Dovgal wrote:
On 14.11.2005 12:55, Roman Ivanov wrote:
wishlist> input filter extension (including some element of user
wishlist> control)
Will it be used _instead_ of $_POST and $_GET?
An extension instead of the arrays?
You must be missin
56 matches
Mail list logo
