On Tue, Aug 24, 2004 at 08:53:15PM -0400, Ilia Alshanetsky wrote:
> What compiler flags are you using that you see this warning message? I do not
> see on the local build here.
gcc -Wall warns, any LP64 platform.
Zend/zend_compile.c: In function `build_runtime_defined_function_key':
Zend/zend_co
Probably 64bit system?
At 08:53 PM 8/24/2004 -0400, Ilia Alshanetsky wrote:
What compiler flags are you using that you see this warning message? I do not
see on the local build here.
Ilia
On August 24, 2004 10:53 am, Joe Orton wrote:
> If casting pointers to integers at least cast to a long, to avo
On Aug 24, 2004, at 7:51 PM, Jason wrote:
Thanks for the feedback.
A way to somehow limit the caching of expressions
would be ideal, otherwise, the memory is lost forever
with no way to reclaim it. I imagine a limited size
cache which keeps only the most used expressions would
be ideal.
If anyone
What compiler flags are you using that you see this warning message? I do not
see on the local build here.
Ilia
On August 24, 2004 10:53 am, Joe Orton wrote:
> If casting pointers to integers at least cast to a long, to avoid
> compiler warnings:
>
> --- Zend/zend_compile.c 23 Aug 2004 20:
Applying right now. Thanks.
Andi
At 12:09 AM 8/25/2004 +, Andrey Hristov wrote:
Hi,
today I saw a note left by a person in the documentation on php.net
about the lack of function named interface_exists(). Currently there is
class_exists() which returns true always when the name is a declared
c
Andrei already fixed it.
-Rasmus
On Tue, 24 Aug 2004, Jason wrote:
> Thanks for the feedback.
>
> A way to somehow limit the caching of expressions
> would be ideal, otherwise, the memory is lost forever
> with no way to reclaim it. I imagine a limited size
> cache which keeps only the most use
Thanks for the feedback.
A way to somehow limit the caching of expressions
would be ideal, otherwise, the memory is lost forever
with no way to reclaim it. I imagine a limited size
cache which keeps only the most used expressions would
be ideal.
If anyone can tell me which source file has the
Hi,
today I saw a note left by a person in the documentation on php.net
about the lack of function named interface_exists(). Currently there is
class_exists() which returns true always when the name is a declared
class or a known interface. However an interface is not a class, some
will say that i
FIFO, with the addition that one that's re-used, will be moved to the
beginning of the list, would (I think) greatly benefit the cache hit-rate.
Just my $0.02
Ron
"Derrell Lipman" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Ilia Alshanetsky <[EMAIL PROTECTED]> writes:
>
> > Thi
> I browser through it and it seems you put it in the HAVE_GETRLIMIT
> define, you might want to add a new config/m4 check for it and use
> HAVE_SETRLIMIT around it. Conceptually I see no reason why we should not
> add it.
Here is updated patch.
--
mg
Index: config.m4
===
On Tue, 24 Aug 2004, Marcin [iso-8859-2] Gibu?a wrote:
> Hi,
> this patch adds posix_setrlimit function (in posix extension), which can be
> useful in standalone apps to lower your resources limits (for example cpu
> limit).
>
> Example usage is:
> $a = array('cpu' => array('1', '3'));
> posix_se
Hi,
this patch adds posix_setrlimit function (in posix extension), which can be
useful in standalone apps to lower your resources limits (for example cpu
limit).
Example usage is:
array('1', '3'));
posix_setrlimit($a);
?>
Could you review it and consider to apply if it's ok?
--
mg
diff -u -
> 29208 Open The variable name which ext_skel
> generates, and the variable name which configu
It this valid? There is a patch attached in the report...
--
mg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
it's worth noting that the crypto-enabled version probably won't work
with PHP without some (simple) patching.
In case it isn't clear, the message is: don't put the files under the
web root. If you provider forces you to do that and offers no other
way to control security, find one that does.
--
I don't get this thread either...
it's no more or less secure than anything else you store in a file.
We are not going to hack libsqlite or change anything else in PHP to
cater for this--it really isn't our problem.
If you have a cheap provider that insists on putting your private data
under the w
Ilia Alshanetsky <[EMAIL PROTECTED]> writes:
> This is not a bug, but rather expected behavior. PCRE extension caches
> compiled regular expressions so that subsequent runs of the same regex do
> not need to perform the compilation step. In your example you are generating
> new regex in an untermi
Shouldn't you be able to disable that cache though?
John
On Tue, 2004-08-24 at 11:53, Ilia Alshanetsky wrote:
> This is not a bug, but rather expected behavior. PCRE extension caches
> compiled regular expressions so that subsequent runs of the same regex do not
> need to perform the compilatio
On Tue, 24 Aug 2004, Adam Q wrote:
I thought more about the issue last night and I guess it can be summaried as
thus:
In skilled hands an SQLite DB can be potentially more secure than a standard
DB - but in unskilled hands the reverse is true, and SQLite becomes seriously
insecure. Standard DBs
This is not a bug, but rather expected behavior. PCRE extension caches
compiled regular expressions so that subsequent runs of the same regex do not
need to perform the compilation step. In your example you are generating new
regex in an unterminated loop, so it's no surprise that PHP eventually
On August 24, 2004 09:10 am, Adam Q wrote:
> Could we have SQLite DB creation "option" that creates the DB with a
> header that begins first 20 chars anyway... ) - either way, I'm going to do some testing
> of Ilia's create table option and see if I can get around it.
No, the reason is that my "s
If casting pointers to integers at least cast to a long, to avoid
compiler warnings:
--- Zend/zend_compile.c 23 Aug 2004 20:58:48 - 1.581
+++ Zend/zend_compile.c 24 Aug 2004 14:50:31 -
@@ -68,7 +68,7 @@
uint char_pos_len;
char *filename;
- char_pos_len = zend_s
At 19:34 23/08/2004, Sterling Hughes wrote:
Saying that just because someone is too stupid to properly lock down their
data store (put outside the web root, run PHP with proper perms, etc.),
makes PHP/SQLite themselves insecure, is like putting coffee on your lap,
driving and blaming McDonalds f
On 24/08/2004, at 12:34 AM, Zeev Suraski wrote:
At 17:16 23/08/2004, Ilia Alshanetsky wrote:
Here is the simple truth, if you are using a shared hosting solution
that is
not VPS (Virtual Private Server) it would be relatively trivial for
other
users of the system to access any file that the webse
Hi guys,
I'm looking for the maintainer of the preg_match
function in PHP. There appears to be a nasty leak in
its most basic functionality, and being a very
fundamental function of PHP (not to mention that my
long running scripts use it a lot ;) I thought I'd try
and go the direct route. Sorry,
24 matches
Mail list logo
