Perhaps better would be to introduce a function:
if (can_include($file)) {
include $file;
}
opcode caches could easily snag this, as we could provide a simple
hook the way we do with stream_resolve_path(). That would actually
make a 0-stat smart autoloader a possibility. Just in case i
Hi!
Yes, but let's not forget we're talking about making this:
While with proper caching, it can be 0 filesystem accesses.
if (can_include($file)) {
include $file;
}
That's exactly what I was proposing - to have function to find file in
include path and probably return the resulting f
Stanislav Malyshev wrote:
> Hi!
>
>> A good point. Fortunately, most streams do store the filename in the
>> stream struct, so this would still probably be possible in the majority
>> of cases. If not available, the original requested filename is used
>> (the one from the fopen call), so opcode c
Hi!
A good point. Fortunately, most streams do store the filename in the
stream struct, so this would still probably be possible in the majority
of cases. If not available, the original requested filename is used
(the one from the fopen call), so opcode caches probably could just use
that.
T
Stanislav Malyshev wrote:
> Hi!
>
>>> This would break security distinction between file ops and include ops,
>>> when URLs are allowed for open but not include.
>
> Additional thing - it probably would be a problem for bytecode caches,
> since they'd have to:
> a. watch all file opens, in case som
On 10.11.2009, at 22:28, Stanislav Malyshev wrote:
Hi!
They dont want to determine if a file exists. They want to be able
to handle the case of a missing file being included differently
than a syntax error. Since php core does not provide such features,
the only
Let's see why they need
On 10.11.2009, at 22:41, Alban wrote:
I think if PHP throws exception instead of warning/error then this
problem will not have existence reason :
sure with exceptions we could provide more contextual information and
also give a local way to handle the situation locally. that being said
f
Le Tue, 10 Nov 2009 21:56:47 +0100, Lukas Kahwe Smith a écrit :
> On 10.11.2009, at 21:31, Stanislav Malyshev wrote:
>
>>> ok .. so your objection to the RFC is solely because it introduces a
>>> new language construct?
>>
>> No, my objection is that it is not necessary to introduce a language
>>
Hi!
They dont want to determine if a file exists. They want to be able to
handle the case of a missing file being included differently than a
syntax error. Since php core does not provide such features, the only
Let's see why they need to handle missing file being included
differently? Or,
On 10.11.2009, at 21:31, Stanislav Malyshev wrote:
ok .. so your objection to the RFC is solely because it introduces
a new language construct?
No, my objection is that it is not necessary to introduce a language
construct, and the construct introduced is not the right one. If
frameworks
Hi!
ok .. so your objection to the RFC is solely because it introduces a new
language construct?
No, my objection is that it is not necessary to introduce a language
construct, and the construct introduced is not the right one. If
frameworks want to find out if file exists or get its name -
Hi!
This would break security distinction between file ops and include ops,
when URLs are allowed for open but not include.
Additional thing - it probably would be a problem for bytecode caches,
since they'd have to:
a. watch all file opens, in case some of these will later be used for
inclu
Stanislav Malyshev wrote:
> Hi!
>
>> Alternatively include() could be extended to allow resources, so the
>> above would turn info
>>
>> if ($fp = @fopen($file, 'r', true)) {
>> include($fp);
>> fclose($fp);
>> }
>
> This would break security distinction between file ops and include ops,
On 10.11.2009, at 20:38, Stanislav Malyshev wrote:
there are many approaches to caching, one of which is delete to
invalidate and regenerate before the next use. again as the RFC
makes it clear .. the purpose is to be able to differentiate
between a syntax error and a missing file.
If yo
Hi!
there are many approaches to caching, one of which is delete to
invalidate and regenerate before the next use. again as the RFC makes it
clear .. the purpose is to be able to differentiate between a syntax
error and a missing file.
If you writing your own cache basing on includes, you ca
On 10.11.2009, at 20:07, Stanislav Malyshev wrote:
Hi!
yes that would solve the issue partially. the race condition would
still remain, but its admitedly a rare case .. well I guess not so
rare if you
I would have hard time thinking of application that deletes its own
include files fre
Hi!
yes that would solve the issue partially. the race condition would still
remain, but its admitedly a rare case .. well I guess not so rare if you
I would have hard time thinking of application that deletes its own
include files frequently from other processes and we are supposed to
hand
On 10.11.2009, at 19:49, Stanislav Malyshev wrote:
Hi!
In order to solve the above issues this RFC proposes the addition
of a new
construct/function for now called “autoload_include” for lack of a
better
name that largely behaves like the “include” does today with the
following
differenc
Hi!
In order to solve the above issues this RFC proposes the addition of a new
construct/function for now called “autoload_include” for lack of a better
name that largely behaves like the “include” does today with the following
differences, that when the include failed because of a missing file
> As stated in the RFC, I am not happy with the name "autoload_include".
> Suggestions welcome!
That reminds me of the set theory...
how about:
contain $file;
or
superset $file;
there are also the not so original (as found in many other languages)
keywords "import" / "load".
Best,
~IF.
--
PH
Stanislav Malyshev wrote:
> Hi!
>
>> Alternatively include() could be extended to allow resources, so the
>> above would turn info
>>
>> if ($fp = @fopen($file, 'r', true)) {
>> include($fp);
>> fclose($fp);
>> }
>
> This would break security distinction between file ops and include ops,
Hi!
Alternatively include() could be extended to allow resources, so the
above would turn info
if ($fp = @fopen($file, 'r', true)) {
include($fp);
fclose($fp);
}
This would break security distinction between file ops and include ops,
when URLs are allowed for open but not inc
Hi!
Whilst you are all thinking about this, how about ...
$value = (function(){return $x;})();
I tried implementing that but it's not straightforward because you need
to keep the result of first call while everything inside () is
calculated (which can be any number of expressions including
On 10.11.2009, at 18:40, Mark Skilbeck wrote:
What's the problem with file_exists() ?
i have explained this in the RFC. for one it does not support the
include path setting. furthermore this does not solve the race
condition and requires more FS operations than my proposal would.
regar
Lukas Kahwe Smith wrote:
Ahoi,
I have written an RFC for a more efficient solution to get rid of the
common fopen() hack inside autoloaders:
if ($fp = @fopen($file, 'r', true)) {
fclose($fp);
include $file;
}
Here is the gist of the proposal:
In order to solve the above issues this RFC propos
On Tue, 10 Nov 2009, Mathieu Suen wrote:
> By looking at the php6 gc I guess you introduce a mark and sweep gc.
> Looking at the *_root function, it also seems that you have a generational
> mark & sweep gc.
>
> I have a couple of question :
>
> How many generation do you have?
>
> What is the
Lukas Kahwe Smith wrote:
> I have written an RFC for a more efficient solution to get rid of the
> common fopen() hack inside autoloaders:
> if ($fp = @fopen($file, 'r', true)) {
> fclose($fp);
> include $file;
> }
>
> Here is the gist of the proposal:
> In order to solve the above issues this RFC
include_silent is the name I though most intuitive once I finished to
read the RFC.
But it may not be the best too. It just need to be verbose.
Cheers,
On Tue, Nov 10, 2009 at 2:45 PM, Lukas Kahwe Smith wrote:
> Ahoi,
>
> I have written an RFC for a more efficient solution to get rid of the com
Ahoi,
I have written an RFC for a more efficient solution to get rid of the
common fopen() hack inside autoloaders:
if ($fp = @fopen($file, 'r', true)) {
fclose($fp);
include $file;
}
Here is the gist of the proposal:
In order to solve the above issues this RFC proposes the addition of a
ne
Scott MacVicar wrote:
On 10 Nov 2009, at 13:55, Mark Skilbeck wrote:
I'm trying to debug a segfault that's occuring in an extension I'm
developing (phpgksu - PHP wrapper for libgksu2). On the PHP site it
says that if I have PHP configured with --enable-debug (which I do)
then whenever PHP cra
On 10.11.2009 16:55, Mark Skilbeck wrote:
> I'm trying to debug a segfault that's occuring in an extension I'm
> developing (phpgksu - PHP wrapper for libgksu2). On the PHP site it says
> that if I have PHP configured with --enable-debug (which I do) then
> whenever PHP crashes a core file shoul
On 10 Nov 2009, at 13:55, Mark Skilbeck wrote:
I'm trying to debug a segfault that's occuring in an extension I'm
developing (phpgksu - PHP wrapper for libgksu2). On the PHP site it
says that if I have PHP configured with --enable-debug (which I do)
then whenever PHP crashes a core file sho
I'm trying to debug a segfault that's occuring in an extension I'm
developing (phpgksu - PHP wrapper for libgksu2). On the PHP site it says
that if I have PHP configured with --enable-debug (which I do) then
whenever PHP crashes a core file should be created in the same directory
the file is ex
jvlad a écrit :
"Mathieu Suen" wrote in message
news:4af91f92.4000...@easyflirt.com...
Why isn't a mater of pushing the function call statement into a valuable
statement?
I guess something like this:
statement :
| value
| function_call;
value :
| valriable
| array_access
| method_send
| ..
"Mathieu Suen" wrote in message
news:4af91f92.4000...@easyflirt.com...
>
> Why isn't a mater of pushing the function call statement into a valuable
> statement?
>
> I guess something like this:
>
> statement :
> | value
> | function_call;
>
>
> value :
> | valriable
> | array_access
> | method_s
Hi,
By looking at the php6 gc I guess you introduce a mark and sweep gc.
Looking at the *_root function, it also seems that you have a
generational mark & sweep gc.
I have a couple of question :
How many generation do you have?
What is the meaning of the different color (black, white, grey)
melfar a écrit :
Hey,
Yep, I think there might be some caveats to that change.
The original patch did not work on methods, so I've fixed that and also
made the return value an rvalue, so that you can't attempt to modify the
temporary value, the zend_check_writable_variable guard will yield an er
37 matches
Mail list logo
