RE: [PHP-DEV] [RFC] Typed Properties

[Bob Weinand]

> From: Marco Pivetta 
> Sent: Thursday, June 21, 2018 01:10
> To: Nikita Popov 
> Cc: PHP Internals List 
> Subject: Re: [PHP-DEV] [RFC] Typed Properties
> 
> Hi Nikita, Bob,
> 
> On Wed, 20 Jun 2018, 23:59 Nikita Popov,  wrote:
> 
> > Hi internals,
> >
> > Bob and I would like to present a new typed properties proposal for
> > your
> > consideration:
> >
> >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki
> >
> .php.net%2Frfc%2Ftyped_properties_v2=02%7C01%7C%7Ca414560298
> 8f413
> >
> 3a54808d5d7031564%7C84df9e7fe9f640afb435%7C1%7C0%7C6
> 366513
> >
> 30591392793=M70Asi8WqXbP6icXeVsdsBuI1GiK9UjgHj9EoZHX4%2Bg
> %3D
> > erved=0
> >
> > The proposal allows you to annotate properties with types, which are
> > enforced at runtime. Unlike the previous RFC on this topic, the new
> > proposal also supports typed static properties and references to typed
> > properties.
> >
> > Please note that next to the main body, the RFC also contains an
> > "Alternatives" section, which explores the problem space and considers
> > trade-offs of different behaviors in some detail.
> >
> > Finally, while this RFC currently targets PHP 7.3, this is a large and
> > complex proposal and we may not be able to meet the deadline, in which
> > case this feature will go into the next PHP version.
> >
> > Regards,
> > Nikita
> >
> 
> This is awesome news! I skimmed over the proposal and it is extremely well
> thought out, and almost everything that was causing a -1 on the previous RFC
> is gone: kudos!
> 
> The last bit that is missing is the `__get` kink, mostly because `__get()` is
> "squishy by design". Still, the fact that references are properly typed
> mitigates the issue for my shady use-cases (I've got a reputation there), so
> I'm quite happy with an implicit magic type check. One thing I couldn't find 
> is
> whether this magic check is also enforced when calling `__get()` explicitly,
> and not via the guards in the engine.
> 
> Is the current development branch usable for testing something locally? I
> can't see any obvious mistakes here, but I just wanted to try this out with
> some of the more obscure libraries that touch property state at the level that
> is covered by this RFC.

__get() is a very normal function - the special semantics are generally only 
applied if called for overloaded properties. So obviously, there is no check 
applied if you call it directly.

The dev branch is stable for testing, yes. Would appreciate reports about any 
bugs you find.

Bob

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

[Marco Pivetta]

Hi Nikita, Bob,

On Wed, 20 Jun 2018, 23:59 Nikita Popov,  wrote:

> Hi internals,
>
> Bob and I would like to present a new typed properties proposal for your
> consideration:
>
> https://wiki.php.net/rfc/typed_properties_v2
>
> The proposal allows you to annotate properties with types, which are
> enforced at runtime. Unlike the previous RFC on this topic, the new
> proposal also supports typed static properties and references to typed
> properties.
>
> Please note that next to the main body, the RFC also contains an
> "Alternatives" section, which explores the problem space and considers
> trade-offs of different behaviors in some detail.
>
> Finally, while this RFC currently targets PHP 7.3, this is a large and
> complex proposal and we may not be able to meet the deadline, in which case
> this feature will go into the next PHP version.
>
> Regards,
> Nikita
>

This is awesome news! I skimmed over the proposal and it is extremely well
thought out, and almost everything that was causing a -1 on the previous
RFC is gone: kudos!

The last bit that is missing is the `__get` kink, mostly because `__get()`
is "squishy by design". Still, the fact that references are properly typed
mitigates the issue for my shady use-cases (I've got a reputation there),
so I'm quite happy with an implicit magic type check. One thing I couldn't
find is whether this magic check is also enforced when calling `__get()`
explicitly, and not via the guards in the engine.

Is the current development branch usable for testing something locally? I
can't see any obvious mistakes here, but I just wanted to try this out with
some of the more obscure libraries that touch property state at the level
that is covered by this RFC.

>

[PHP-DEV] [RFC] Typed Properties

[Nikita Popov]

Hi internals,

Bob and I would like to present a new typed properties proposal for your
consideration:

https://wiki.php.net/rfc/typed_properties_v2

The proposal allows you to annotate properties with types, which are
enforced at runtime. Unlike the previous RFC on this topic, the new
proposal also supports typed static properties and references to typed
properties.

Please note that next to the main body, the RFC also contains an
"Alternatives" section, which explores the problem space and considers
trade-offs of different behaviors in some detail.

Finally, while this RFC currently targets PHP 7.3, this is a large and
complex proposal and we may not be able to meet the deadline, in which case
this feature will go into the next PHP version.

Regards,
Nikita

Re: [PHP-DEV] [RFC][Under Discussion] Add functions array_key_first()and array_key_last()

[Rowan Collins]

On 20 June 2018 at 17:19, Levi Morrison  wrote:

> Bad behavior of existing functions does not mean we should create new
> functions with the same bad behavior. If you believe lack of education
> regarding array destructuring is an issue then we can use this example
> specifically in the docs for these functions; problem solved.
>


I'm torn between your point of view and Enno's.

Note that we're not talking about "lack of education regarding array
destructuring", because there's no array being destructured; we're talking
about "lack of education regarding the side-effect behaviour of the array
destructuring operator when given a non-array input". It's a pretty
obscure, seemingly undocumented, language feature, and one which the RFC
you linked seems to have originally classed as unwanted behaviour.

If it was used in a prominent example, maybe other uses for this idiom
might start cropping up, and people would start using it. Even so, if I saw
it while reviewing or debugging code, I would probably be tempted to
refactor it to something "less clever" so that the intent was clearer.

On balance, I don't think the example you gave is a compelling reason, on
its own, to go with your suggested signature. The separate functions feel
more convenient in a lot of cases, but maybe less so in others.

Regards,
-- 
Rowan Collins
[IMSoP]

Re: [PHP-DEV] [RFC][Discussion] iterable_to_array() and iterable_count()

[Johannes Schlüter]

On Mi, 2018-06-20 at 03:55 +0200, Michael Moravec wrote:
> Hello internals,
> 
> I'd like to propose two new functions for PHP 7.3:
> iterable_to_array() and
> iterable_count()
> 
> These functions are supposed to work with iterables (7.1 pseudotype)
> - both arrays and iterators, unlike iterator_*() functions which only
> work with iterators.
> 

Is there any reason not to extend the existing functions to also allow
arrays?

Also for the count one: Mind that iterator_count()/iterable_count()
doesn't respect the Countable interface and consumes the iterator,
which might not be resetable. A slightly better choice might be

    (is_array($iterable) || implements_countable($iterable)) ? 
          count($iterable) : iterator_count($iterable)

And even then I would put a warning sign against blindly using it on
any iterator.

johannes


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][Under Discussion] Add functions array_key_first()and array_key_last()

[Levi Morrison]

On Wed, Jun 20, 2018 at 10:03 AM Woortmann, Enno  wrote:
>
> Am 20.06.2018 um 15:55 schrieb Levi Morrison:
> > Your wish cannot be granted for `array_value_last` and
> > `array_value_first`; you cannot know by itself if there is a failure
> > condition.
>
> I can comprehend your issue with the lack of distinctness between the
> error case and the 'real' array value null without further checks.
> But in my opinion the required additional checking of the $input is a
> learned behaviour from existing functions which handle single value
> elements from an array as reset(), current() and end() will return false
> for empty arrays or null for invalid data types which are both also
> valid element values.
> array_pop() and array_shift() also behave in a comparable way as they
> return null as well for empty arrays as for non array input.
> > This is not "clean". In contrast here is with my proposal:
> >
> >  if ([$key, $value] = array_last($input) {
> >  // do something
> >  }
> I still think that this proposed syntax is unintuitive and hard to
> comprehend for the user of the function.
> I don't think many PHP developers out there know that the condition
> inside the if will evaluate to null if array_last returns null.
>
> Additionally I don't know about any other function where a construct
> like this has to be used to extract two or more different semantic
> entities, in this case the key and the value, out of a PHP core function
> return value.

Bad behavior of existing functions does not mean we should create new
functions with the same bad behavior. If you believe lack of education
regarding array destructuring is an issue then we can use this example
specifically in the docs for these functions; problem solved.

We can do better and I've shown how we can do better. Please adopt it.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][Under Discussion] Add functions array_key_first()and array_key_last()

[Woortmann, Enno]

Am 20.06.2018 um 15:55 schrieb Levi Morrison:

Your wish cannot be granted for `array_value_last` and
`array_value_first`; you cannot know by itself if there is a failure
condition.


I can comprehend your issue with the lack of distinctness between the 
error case and the 'real' array value null without further checks.
But in my opinion the required additional checking of the $input is a 
learned behaviour from existing functions which handle single value 
elements from an array as reset(), current() and end() will return false 
for empty arrays or null for invalid data types which are both also 
valid element values.
array_pop() and array_shift() also behave in a comparable way as they 
return null as well for empty arrays as for non array input.

This is not "clean". In contrast here is with my proposal:

 if ([$key, $value] = array_last($input) {
 // do something
 }
I still think that this proposed syntax is unintuitive and hard to 
comprehend for the user of the function.
I don't think many PHP developers out there know that the condition 
inside the if will evaluate to null if array_last returns null.


Additionally I don't know about any other function where a construct 
like this has to be used to extract two or more different semantic 
entities, in this case the key and the value, out of a PHP core function 
return value.


Enno

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][Under Discussion] Add functions array_key_first()and array_key_last()

[Rowan Collins]

On 20 June 2018 at 15:29, Levi Morrison  wrote:

> > Ah, OK, you learn something every day! For anyone else like me who was
> unaware of this, list() apparently silently accepts any non-array value on
> the right of the assignment, assigns all variables in the list() to null,
> and evaluates to the assigned (but otherwise unused) value. So
> $x=list($a,$b)=42; will set $a and $b to NULL, and $x to 42, without any
> notices.
>
> This is changing as per this RFC:
> https://wiki.php.net/rfc/notice-for-non-valid-array-container. The
> `null` case is kept.
>


Not according to the RFC:

> Per discussion on the PR
 I have
limited this RFC to not raise warnings when setting any value by use of
list().

It says nothing about treating NULL specially, it just implies list() will
be out of scope of the RFC completely.

Regards,
-- 
Rowan Collins
[IMSoP]

Re: [PHP-DEV] [RFC][Under Discussion] Add functions array_key_first()and array_key_last()

[Levi Morrison]

> Ah, OK, you learn something every day! For anyone else like me who was 
> unaware of this, list() apparently silently accepts any non-array value on 
> the right of the assignment, assigns all variables in the list() to null, and 
> evaluates to the assigned (but otherwise unused) value. So $x=list($a,$b)=42; 
> will set $a and $b to NULL, and $x to 42, without any notices.

This is changing as per this RFC:
https://wiki.php.net/rfc/notice-for-non-valid-array-container. The
`null` case is kept.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][Under Discussion] Add functions array_key_first()and array_key_last()

[Rowan Collins]

On 20 June 2018 at 15:10, Levi Morrison  wrote:

> On Wed, Jun 20, 2018 at 8:09 AM Rowan Collins 
> wrote:
> >
> > On 20 June 2018 at 14:55, Levi Morrison  wrote:
> >>
> >>
> >> if ([$key, $value] = array_last($input) {
> >> // do something
> >> }
> >>
> >
> >
> > Unfortunately, this won't work. I didn't know list() could even be used
> as an expression, but apparently if it is, it evaluates to the whole array
> on its right-hand side, which makes sense.
> >
> > So, if array_last([]) returns [null, null], then [$key,
> $value]=array_last([]) will also evaluate to [null, null]. Since that's not
> an empty array (it has two elements in it), it will evaluate to true.
> https://3v4l.org/lIEa1
> >
> > If, on the other hand, array_last([]) returned something empty, like [],
> the list() assignment would throw Notices for the implicit access to
> elements [0] and [1] of the empty array. https://3v4l.org/qhq5R
>
> It returns `?array`. So either `null` or `[$key, $value]`. There are
> no notices; sorry for the lack of detail.
>


Ah, OK, you learn something every day! For anyone else like me who was
unaware of this, list() apparently silently accepts any non-array value on
the right of the assignment, assigns all variables in the list() to null,
and evaluates to the assigned (but otherwise unused) value. So
$x=list($a,$b)=42; will set $a and $b to NULL, and $x to 42, without any
notices.

I don't think I would ever have expected that behaviour, but apparently
it's been that way forever, so I guess it's fine to exploit it.

Incidentally, there's no mention of this on the manual page, which is also
missing information on the short-hand syntax and key-based destructuring
introduced in PHP 7.1: http://php.net/list

Regards,
-- 
Rowan Collins
[IMSoP]

Re: [PHP-DEV] [RFC][Under Discussion] Add functions array_key_first()and array_key_last()

[Nicolas Grekas]

> It returns `?array`. So either `null` or `[$key, $value]`. There are
> no notices; sorry for the lack of detail.
>

See https://3v4l.org/2hX3Y for example

Re: [PHP-DEV] [RFC][Under Discussion] Add functions array_key_first()and array_key_last()

[Levi Morrison]

On Wed, Jun 20, 2018 at 8:09 AM Rowan Collins  wrote:
>
> On 20 June 2018 at 14:55, Levi Morrison  wrote:
>>
>>
>> if ([$key, $value] = array_last($input) {
>> // do something
>> }
>>
>
>
> Unfortunately, this won't work. I didn't know list() could even be used as an 
> expression, but apparently if it is, it evaluates to the whole array on its 
> right-hand side, which makes sense.
>
> So, if array_last([]) returns [null, null], then [$key, 
> $value]=array_last([]) will also evaluate to [null, null]. Since that's not 
> an empty array (it has two elements in it), it will evaluate to true. 
> https://3v4l.org/lIEa1
>
> If, on the other hand, array_last([]) returned something empty, like [], the 
> list() assignment would throw Notices for the implicit access to elements [0] 
> and [1] of the empty array. https://3v4l.org/qhq5R

It returns `?array`. So either `null` or `[$key, $value]`. There are
no notices; sorry for the lack of detail.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][Under Discussion] Add functions array_key_first()and array_key_last()

[Rowan Collins]

On 20 June 2018 at 14:55, Levi Morrison  wrote:

>
> if ([$key, $value] = array_last($input) {
> // do something
> }
>
>

Unfortunately, this won't work. I didn't know list() could even be used as
an expression, but apparently if it is, it evaluates to the whole array on
its right-hand side, which makes sense.

So, if array_last([]) returns [null, null], then [$key,
$value]=array_last([]) will also evaluate to [null, null]. Since that's not
an empty array (it has two elements in it), it will evaluate to true.
https://3v4l.org/lIEa1

If, on the other hand, array_last([]) returned something empty, like [],
the list() assignment would throw Notices for the implicit access to
elements [0] and [1] of the empty array. https://3v4l.org/qhq5R

Regards,
-- 
Rowan Collins
[IMSoP]

Re: [PHP-DEV] [RFC][Under Discussion] Add functions array_key_first()and array_key_last()

[Nicolas Grekas]

> if ([$key, $value] = array_last($input) {
>

+1 for this proposal, I would even go one step further and suggest a single
function, with an index as second argument:

`if ([$key, $value] = array_index($input, $index) {`

when `0 === $index` => returns the first, `-1 === $index` returns the last,
etc.

Re: [PHP-DEV] [RFC][Under Discussion] Add functions array_key_first()and array_key_last()

[Levi Morrison]

On Wed, Jun 20, 2018 at 3:17 AM Woortmann, Enno  wrote:
>
> Hi Levi,
>
>
> Am 20.06.2018 um 04:47 schrieb Levi Morrison:
> >  list($key, $value) = array_first($input);
> >  // $key will be null if the call failed
> >
> >  list($key, $value) = array_last($input);
> >  // $key will be null if the call failed
>
> Your proposed functions would be implementable with the internal
> functions but I think this approach doesn't provide a clean function
> interface as it forces the user to evaluate the wanted value from the
> returned array structure by using either the list() construct or
> something like $key = array_first($input)[0];
>
> I believe two functions with this interface will be confusing and less
> intuitive for the developer.
> If I use a function I expect it to give me a return value which I can
> use without any further post processing $wantedValue =
> fancyFunction($someInput);

Your wish cannot be granted for `array_value_last` and
`array_value_first`; you cannot know by itself if there is a failure
condition. As proposed you have to write:

if (!empty($input)) {
$value = array_value_last($input)
// do something
}

This is not "clean". In contrast here is with my proposal:

if ([$key, $value] = array_last($input) {
// do something
}

If I need the last/first key and value (which is a real use-case and
why I thought of this in the first place) then in your proposal I have
to do:

if (!empty($input)) {
$key = array_key_last($input);
$value = array_value_last($input);
   }

Or use the key to get the value; roughly the same amount of code.
Either way is not as clean as:

if ([$key, $value] = array_last($input) {
// do something
}

Hopefully I have shown that for various use-cases the proposed
interface is cleaner and that you cannot argue against it on those
grounds.

Adding 4 functions which cover 4 use-cases, with ugly names, and 2 of
them having poor failure semantics is not a good direction. Adding
only 2 functions which cover 6 use-cases, with nice names, and good
failure conditions is better. Please reconsider.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][Under Discussion] Add functions array_key_first()and array_key_last()

[Gabriel Caruso]

>
>  don't think I'm getting all the mail I am supposed to. I hope this gets
> seen.
>
> I propose 2 functions *only* which I believe covers the use-cases that
> all 4 of these do and more, with shorter names, and the ability to
> discern whether the call succeeded or not.
>
> list($key, $value) = array_first($input);
> // $key will be null if the call failed
>
> list($key, $value) = array_last($input);
> // $key will be null if the call failed
>
> I have tested it with user-land functions and seems to work as
> intended in all success and failure conditions. Verification that it
> works as intended with internal functions is necessary but this seems
> a much better proposal to me.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php


Hi Levi.

I have plans to bring an `array_find_first` and `array_find_last` to the
next PHP 7.x. It will basically work:

$firstUserWithUsername = array_find_first(function (User $user): bool {
return $user->username !== null;
}, $users);

Just wanted to point that to alert that someone is working on that :)
-- 
Gabriel Caruso

Re: [PHP-DEV] Cleaning up unmaintained extensions - interbase

[Lester Caine]

On 20/06/18 10:25, Nikita Popov wrote:

Just to clarify which bug I was referring to in that mail, it's this one:
https://bugs.php.net/bug.php?id=72175

There are three issues that must be addressed:
  * The issue in the original bug report: Connecting to the same DB multiple
times does not work.
  * The use of zend_list_delete() in *_close() functions, which is
memory-unsafe.
  * Incorrect interaction of closing and multiple shared connections. While
the underlying connection is shared, closing one resource should not close
all the other ones, but also not result in any leaks (this ties into the
previous point -- you can't just use zend_list_delete for that!) You may
need to implement a double resource indirection to properly handle this,
one holding the actual connection and another holding the connection
resource.

If you or someone who is familiar with interbase could fix these issues,
that would be highly appreciated.


Is there anything in the changes to the code in PHP7 that are ACTUALLY 
to do with changes to interbase/firebird? On website systems I only ever 
have a 'singleton' database connection so don't hit this problem, but 
having just spent half an hour looking through the various notes on 
different lists it seems to be the way zend handles resources in PHP7 
rather than anything to do with the database? THIS is where the nuances 
of PHP7 need to be understood to be able to read your third point ... 
where does one need to understand how the database works?


I am assuming that my next step here is to work out how 
zend_list_delete() is intended to be used, perhaps compare that with 
it's use in other database drivers, and work out just what was broken in 
7.0.3 and why ... and "implement a double resource indirection" ... 
which is much easier to implement if you understand why it is now necessary?


--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Cleaning up unmaintained extensions - interbase

[Nikita Popov]

On Tue, Jun 19, 2018 at 11:47 PM, Lester Caine  wrote:

> On 19/06/18 21:48, Stanislav Malyshev wrote:
>
>> What Bug!
>>> It's passing all the test that I run on it perfectly stably otherwise I
>>> would not even bother with PHP7. But the problem supporting ANY driver
>>> is the exotic nature of PHP is just as difficult as the tools it needs
>>> to interface with to make a fully functional stack ...
>>>
>> I have four bugs for interbase and four for firebird submitted just
>> recently, as security issues. Do you want to take care of them? I can
>> assign them to you if you want to take care of them.
>>
>
> The last time I managed to patch php was over 15 years ago, I have not
> been able to get a handle on the new structure used by PHP7 in part because
> I've not had time to do any C coding since. I'm still working on moving
> PHP5.2 code to work on PHP7 while keeping the stack working on W10 and
> maintained versions of SUSE Linux. And some of the stuff I thought I'd
> finished upgrading is not working again :(
>
> I'm not seeing any bugs listed in bugs.php.net that are security risks. I
> don't touch PDO_firebird as it does not handle key Firebird features so
> looking at 'InterBase related' only returns 8 bugs, and one of them is
> missing documentation on the fbird_ aliases that I use in the ADOdb
> Firebird driver. THAT is something I do spend time keeping tidy, and fixes
> some of the niggles raw access encounters, but I will have a look at the
> 2017 bugs that I'd not been aware of ... the other bugs are somewhat exotic
> but not security matters.


Just to clarify which bug I was referring to in that mail, it's this one:
https://bugs.php.net/bug.php?id=72175

There are three issues that must be addressed:
 * The issue in the original bug report: Connecting to the same DB multiple
times does not work.
 * The use of zend_list_delete() in *_close() functions, which is
memory-unsafe.
 * Incorrect interaction of closing and multiple shared connections. While
the underlying connection is shared, closing one resource should not close
all the other ones, but also not result in any leaks (this ties into the
previous point -- you can't just use zend_list_delete for that!) You may
need to implement a double resource indirection to properly handle this,
one holding the actual connection and another holding the connection
resource.

If you or someone who is familiar with interbase could fix these issues,
that would be highly appreciated.

Thanks,
Nikita

Re: [PHP-DEV] [RFC][Under Discussion] Add functions array_key_first()and array_key_last()

[Woortmann, Enno]

Hi Levi,


Am 20.06.2018 um 04:47 schrieb Levi Morrison:

 list($key, $value) = array_first($input);
 // $key will be null if the call failed

 list($key, $value) = array_last($input);
 // $key will be null if the call failed


Your proposed functions would be implementable with the internal 
functions but I think this approach doesn't provide a clean function 
interface as it forces the user to evaluate the wanted value from the 
returned array structure by using either the list() construct or 
something like $key = array_first($input)[0];


I believe two functions with this interface will be confusing and less 
intuitive for the developer.
If I use a function I expect it to give me a return value which I can 
use without any further post processing $wantedValue = 
fancyFunction($someInput);


Enno

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Cleaning up unmaintained extensions - interbase

[Lester Caine]

On 20/06/18 06:04, Stanislav Malyshev wrote:

php7 builds are not that different from php5 builds, and I suspect the
issues discovered are also present in earlier versions.


Marius has had more luck understanding the nuances of changes and 
massaging my previous attempts in with his fixes, but I don't think 
either of us are totally comfortable with the C end of things! Things 
have changed somewhat in the 40 years since I got my MSc in 'Digital 
Systems' and today even PHP is black magic at times :(



I'm not seeing any bugs listed in bugs.php.net that are security risks.

Security issues are not publicly visible. If you have php account, I
could assign them to you and you could see them. Or I could arrange a
copy for you, if you intend to work on them.


Current builds of Interbase and Firebird are moving further apart and 
security is one area affected. It may well be that we need to split out 
the Firebird aliases and current builds of Firebird 3 have different 
security layers to FB2.x and Interbase now. I would at least like to see 
a copy of what we are talking about and see if I have any chance of 
being able to work on them ...


You consider Firebird a niche area, and similarly the Firebird 
developers consider PHP the same as the main application software is 
Delphi and C/C++ so trying to get help from either end has always been a 
battle. But for me it is still a much more reliable base than MySQL yet 
new users have little option but to live with second grade tools.


I'm not sure just what accounts I have on PHP these days. I used to have 
logins but I forget nowadays what for. I would just like to get back to 
producing content rather than firefighting changes every day ...


--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php