Well, there is an alternative to telling users to change their, code you
can force them to :-)
PHP allows setting of default connection parameters for mysql_connect()
via INI settings and subsequently disabling (turn on SQL safe mode) the
ability to specify them directly.
The ext/MySQL ini s
Why not simply instruct your developers to use the proper host name in
the first place?
Ilia
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Stanislav Malyshev wrote:
GS>>Perl's goto specifically forbids jumping into control structures that
GS>>require intialization (for instance, foreach()). That seems like a
GS>>sensible limitation to me.
jumping out is no good either.
If jumping in/out of foreach is the only technical proble
Stanislav Malyshev wrote:
GS>>I don't think I've ever heard Perl or C maligned on the basis of their
GS>>support for goto. Perhaps I just travel in the wrong circles.
I didn't ever saw any need in Perl goto - except for goto& construct which
isn't goto at all. As for C goto - it's usually use
Stanislav Malyshev wrote:
IA>>Ok, so you propose that people start using exceptions for OO and
IA>>procedural code just because they are "there"? One major problem with
No, I don't propose that. I am just concerned once you put goto there it
would be abused in all kinds of "creative" ways and
Stanislav Malyshev wrote:
IA>>Most common solution people choose to emulate exceptions often ends up being
IA>>recursive functions, those as well know in many instances result in crashes.
Eh? Only case I know when recursion may result in crash is if it's endless
recursion (or recursion for all
Stanislav Malyshev wrote:
finally construct should do that, I think. IMO that's the right solution,
not goto's - and anyway if you allow goto only inside same block, what if
error condition happens inside other block? Are all your functions flat
without control blocks? What if exception happens
Yes, Sara made a patch for it..
http://pecl.org/patches/opcode_goto_5.1.0.diff
I don't know if this is the latest one or not.
+1 for the goto patch in 5.1
Ilia
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Adam,
Perhaps the mentoring FAQ will give you a clue why, specifically the
"What is the role of a mentoring organization?" portion. :-)
http://code.google.com/mentfaq.html
Ilia
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Zeev Suraski wrote:
If it was an issue that everyone and their dog was bumping into, then I
may have thought differently - but it's an issue that is rare enough,
and can be worked around. And those that really need it to be fixed -
can use the patch.
There were a few suspicious bugs that wer
Parameter removed again. Any complaints to add this patch (lowlevel file
io to streams in sha1_file & md5_file) to PHP_5_0 (PHP_4_3 ???), too?
I have no objections to MFHing the path to 4.3.
Ilia
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsu
Andrey Hristov wrote:
Because both functions are in HEAD and still the API is not released
I would appreciate if time_nanosleep() is renamed to nanosleep().
time_sleep_until() "emulate" a system function but uses it and in this
case maybe the name may stay the same.
To rephrase, if there are no ob
Marcus Boerger wrote:
i very much dislike that idea because a mysql3 will never be working as
expected. It can never support multiple statements at a time or transactions
or whatnot. Thus i pretty much want something that keeps me from using it
until i am pretty sure i really can live with that.
The PHP Development Team would like to announce the immediate release of
PHP 4.3.11 and 5.0.4. These are maintenance releases that in addition
to fixing over 70 non-critical bugs, address several security issues.
The addressed security issues include fixes to the exif and fbsql
extensions, as
Hmm.. I was wondering if we should go one step further and also provide
a stream to the data. If the most common usage of this construct is
going to be reading the data after __HALT_PHP_PARSER__ then we should
optimize for that case. Something like
...
I would suggest keeping such implementat
Moriyoshi Koizumi wrote:
Hi,
I modified your patch so it can capture the position where the
supposed data begins into the constant __HALT_PHP_PARSER__.
There may be a problem with my patch if more than one require()'d /
include()'d script contain __HALT_PHP_PARSER__, but it'd be
quite handy if such
Sara Golemon wrote:
Just a nudge about this code approach.
#1 It doesn't detect EOF
Well, if you encounter EOF before the HALT tag, it means as a developer
of the script you are trying to break your own code ;-)
#2 It forgets about the newline returned by fgets(
True, I suppose strncmp could
Wez Furlong wrote:
If you name the token __HALT_PHP_PARSER__ instead (or something
equally unlikely to be used by accident and unambiguous in meaning),
you'll get a +1 from me :-)
I aim to please ;-) Here is the revised patch that makes the token a bit
clearer and also increases the strictness of
Daniel Convissor wrote:
Interesting. I'm wondering about the security implications of this.
This makes it very easy to use PHP as a means to propogate all sorts of
nasty things.
You can already use PHP to propagate all sorts of nasty things, nothing
changes in this respect.
Well, people coul
Would the data after that point be sent directly to STDOUT? Or would the
present script somehow be able to use it?
The data will not be parsed or output. When you need it you would make
the script open itself and read the (binary) data dump from the end of
the file and use it various creative w
The attach patch implements a special "token" that can be
used to stop the Zend lexical parser from parsing any data after this
token.
The idea behind this patch is to allow tucking on of any data (binary
and otherwise) to the PHP script without having to encode it. It also
saves on memory/cp
Good point, +1 for revert.
Ilia
Zeev Suraski wrote:
Guys,
I'd like to revert the fix for bug #31672 (" is not considered
closing tag if preceded by one-line comment"). While theoretically
correct, I'd rather resolve it by fixing the docs.
The reason is simple - unlike ?> and %>, the string "" i
IMHO this is a bit to specialized to be included by default.
Ilia
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Here is a slightly shorter solution to the problem, which hopefully will
prove to be a little bit faster as well.
Ilia
Index: main/main.c
===
RCS file: /repository/php-src/main/main.c,v
retrieving revision 1.512.2.58
diff -u -a -r1.5
IMO this is something that should be marked as Won't Fix and hope that
by PHP 5.2 we can drop register_globals all together. Heck, perhaps we
can do it for PHP 5.1.
Ilia
Andi Gutmans wrote:
This behavior makes some sort of sense. It happens when register_globals
is on which means you are suppos
C++ is not PHP and the sooner you realize this the better it will be.
Adding operator overloading will add yet another layer of "magic" that
will confuse users, who for the most part have demonstrated that they
are not ready for such features. If anything it'll only over complicate
applications
I see no point in introducing this feature which is aimed at solving the
XSS and other related security issues once and for all across all PHP
applications while at the same time providing a completely insecure side
door. Dealing with security issues is a pain in the ass. This pain
doesn't go
Looking at my code here, it would actually be trivial to expose the raw
data as superglobals, but what do we achieve then? We are simply
renaming $_GET to $_GET_RAW or something like that? If you don't want
any filtering to be done by default, simply don't turn it on.
In many cases it may not
Given that we'd always need to store the raw request data in memory, can
we provide some mechanism of accessing it that does not require a
function call? If working with integer or floating point based data it
is much faster and simpler to just do (int)/(float) cast rather then
executing functi
Jay,
I've noticed that you're still using the ini parser in this new code,
would it not be easier and allow for greater code re-use to use the CSV
database and the underlying fgetcsv code?
Ilia
Jay Smith wrote:
Andi Gutmans wrote:
Hey,
I just heard from Wez that PDO is in very advanced stages n
Jochem Maas wrote:
the point
stands that php5 also gets unproductive coverage, and both camps working
together make a much greater force against any FUD.
Any new release that in some situations breaks backwards compatibility
will get some negative press. Ultimately, in successful products a poin
mehow missed it. Or am I
remembering wrong?
-adam
On Wed, 22 Dec 2004, Ilia Alshanetsky wrote:
Of the common issues that are still unresolved there is also the
apparent breakage of COM as of the new release. I'd like to address that
before moving forward with .11. There are also some issues lef
Andi Gutmans wrote:
Am I right to assume COM is 4.3.x only?
Yes, that is correct. But the problems (not present in prior versions)
that appeared in an extension who's code didn't change one bit since
previous release is probably a sign of other issues.
Ilia
--
PHP Internals - PHP Runtime Develop
Of the common issues that are still unresolved there is also the
apparent breakage of COM as of the new release. I'd like to address that
before moving forward with .11. There are also some issues left with the
strtod compilation, although the majority have been resolved by Jani.
Ilia
Edin Kadr
As long as we retain copies of those releases somewhere (php museum) I
see no reason to keep releases older then 3 versions in the
distributions folder.
Ilia
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
PHP Development Team would like to announce the immediate release of PHP
4.3.10 and 5.0.3. These are maintenance releases that in addition to
non-critical bug fixes address several very serious security issues.
These include the following:
CAN-2004-1018 - shmop_write() out of bounds memory write
The 4.3.10RC2 was just released. Hopefully it will be the last release
candidate before the final release that will happen within one week if
the RC proves to be stable. This is the last chance to resolve any
critical bugs before 4.3.10, if you are of aware of any such issues now
is the time to
I believe that there was an all around agreement and this and given that
we are nearing release of 5.0.3 and 4.3.10 this would be a perfect
opportunity to do it. Otherwise it'll need wait for unknown number of
months till the next release.
Ilia
--
PHP Internals - PHP Runtime Development Mailing
I have no objection to removing the Experimental tag from the extension,
in fact I welcome this change.
Ilia
Marcus Boerger wrote:
Hello Christian,
Friday, December 3, 2004, 8:20:33 AM, you wrote:
Ok. There was no real argument against not removing the EXPERIMENTAL tag
and IMHO it isn't experim
Fixed, thanks for the report.
Ilia
Frank M. Kromann wrote:
Hello Everyone,
Line 100 in zend_strtod.c has a space after the \ at the end of the line.
This breaks the win32 build.
- Frank
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Same logic is applicable, in the event of failure false or invalid
resource maybe returned.
Ilia
Markus Bertheau wrote:
Ð ÐÐÐ, 08.11.2004, Ð 16:33, Ilia Alshanetsky ÐÐÑÐÑ:
The error functions do so because they are likely to be called if
creation of a connection fails so there may not always be
The error functions do so because they are likely to be called if
creation of a connection fails so there may not always be a valid
resource. The state checking function would presumably be only run on a
valid connection and consequently should be strict about the resource
parameter (IMO).
Ili
On large arrays (Ex. $GLOBALS) this patch seems to have ~10% speed
improvement on PHP 5.
Ilia
Andi Gutmans wrote:
Still behind a bit on my email. Has anyone tested this yet? It would be
cool to commit.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.
#x27;
IMO at least there is no need for range like $a{-4:2}
Andrey
Ilia Alshanetsky wrote:
IMO {-1} syntax is not only faster but simpler to use then the
equivalent substr() (for read) or $a[strlen($a) - 1] (for write).
While my reasons are primarily performance based, I think that most
people
IMO {-1} syntax is not only faster but simpler to use then the
equivalent substr() (for read) or $a[strlen($a) - 1] (for write). While
my reasons are primarily performance based, I think that most people
would find the {-1} simpler to use as well.
Ilia
Sterling Hughes wrote:
i hope not. this
Andrey Hristov wrote:
Andy mentioned that he tried in the past to separate {} and [] but after
some unsuccess he left the idea of separating. So, the patch definitely
won't be 2-3 lines of code.
I am well aware that at this point PHP has no separation between [] and
{} as far as string offsets go.
e( $p < strlen($p) )
.. do stuff that could do $p-- or $p++
echo $a{$p};
}
at present that would produce a nice error if you went < 0.. easy to
spot.. - if -ve was supported it could do unexpected stuff..
Regards
Alan
Ilia Alshanetsky wrote:
I am wondering what are people's o
Derick Rethans wrote:
- Adding new language constructs in mini releases is IMO not the way to
go as it will make it possible impossible to run script that use this
new construct not even parse on PHP 5.0.x servers. Adding normal new
functions does not have this problem of course, as those scr
Derick Rethans wrote:
How can you *need* this, you can use substr() just fine.
Almost no peace of functionality in PHP in unique, some extensions
duplicate core/standard functionality and vice versa. Usually the "core"
offers a simpler access to a resource and full pledged extensions
gives the
Sure, I have no operator preference.
Ilia
Sterling Hughes wrote:
why not add it with the {} operators then?
-sterling
On Fri, 29 Oct 2004 15:07:05 -0400, Ilia Alshanetsky <[EMAIL PROTECTED]> wrote:
I am wondering what are people's opinions on adding support for negative
string offsets
I am wondering what are people's opinions on adding support for negative
string offsets that could be used to access data from the end of a string.
Ex. $a = "123"; echo $a[-1]; // would print 3
I don't think we should do this for arrays, since -1 and similar are
valid array keys, which means add
Derick Rethans wrote:
For that the granularity is not good enough though.
Ideally we'd have gettimeofday() cached, but looking @ the code it is
called on by lcg code and then only on MINIT. So we'd need an "extra"
syscall to provide this, I am not sure this is a good idea.
Ilia
P.S. I didn't ind
As of PHP 5.1, the request start time is stored by PHP inside the sapi
structure. This data is populated by the information offered by the SAPI
(Apache sapis populate it) otherwise time(0) is used to get the same data.
This means that PHP has a "free" unix timestamp that tells information
about
Joe Orton wrote:
Then consider this your official wake-up call :)
LOL. I use Apache 1.3 and found it to work way better then 2.0. 2.0 does
not offer any useful improvements over the 1.3 base, so why switch? If
anything in my personal experience 1.3 works way better then 2.0 with PHP.
Ilia
--
PHP
Very interesting numbers, I'd like to second Marcus' request for a 4.3
benchmark.
I was somewhat surprised by O2 and O1 being slower then Os, while O3 in
some cases may end over optimizing which would it explain it's poor
showing. However, it could be that it makes simple situations slower,
wh
Here is the proposed 4.3.9 release announcement.
PHP Development Team is proud to announce the immediate release of PHP
4.3.9.
This is a maintenance release that in addition to over 50 non-critical
bug fixes, addresses a problem
with GPC input processing. This release also re-introduces ability t
The final release candidate of PHP 4.3.9 is now available for testing. Hf no
new problems are uncovered, this release will be re-released as 4.3.9 at the
end of the week. If you have any patches (4.X tree) for non-critical problems
please hold them off either until we decide that another RC is n
The final release candidate of PHP 4.3.9 is now available for testing. Hf no
new problems are uncovered, this release will be re-released as 4.3.9 at the
end of the week. If you have any patches (4.X tree) for non-critical problems
please hold them off either until we decide that another RC is n
On August 27, 2004 11:31 am, Hartmut Holzgraefe wrote:
> Derick Rethans wrote:
> >>Aren't PECL package version numbers already providing this?
> >
> > But not everything is in PECL :)
>
> any bundled extensions that are still EXPERIMENTAL should
> move to PECL anyway IMHO
+1
Ilia
--
PHP Interna
On August 27, 2004 03:26 am, Zeev Suraski wrote:
> Me too.
> I would like to get some feedback about my suggestion to move away from the
> simple 'experimental' status and dividing it into two - quality rating, and
> 'API subject to change' tagging. Does this make sense to anybody else?
As long a
On August 25, 2004 08:32 pm, Naik, Roshan wrote:
> " And exactly how long is it expected to continue to stay EXPERIMENTAL
> ?"
>
> The response was a predictable one, expressing indifference...
>
> "Between 15 days and 15 months"
I'm afraid Derick's response was somewhat incorrect. Here is a
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:
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
On August 23, 2004 12:34 pm, Zeev Suraski wrote:
> The point is that hosting companies, especially those using chroot, have to
> make sure that they don't force their users to store the database files in
> web-accessible locations, since the server is most probably designed to be
> able to serve fi
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 webserver has access to. Now,
because webserver will need access privileges to various PHP config
On August 12, 2004 03:47 pm, Andi Gutmans wrote:
> OK guys. I'd like to roll so please check this problem and give me an ack
> if it's OK.
Should be ok now.
Ilia
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Chuck already applied a patch that should resolve the problem that Jan had
reported.
Ilia
On August 12, 2004 02:21 pm, Andi Gutmans wrote:
> At 05:55 PM 8/12/2004 +0200, Jan Schneider wrote:
> >Zitat von Jan Schneider <[EMAIL PROTECTED]>:
> >>Ilia Alshanetsky wrote:
>
On August 12, 2004 04:55 am, Ron Korving wrote:
> Do you know when fixes in PHP4.3.9 will find its way to PHP5?
All of the patches applicable 5.X tree are applied at the same time as they
are to 4.3.X tree.
Ilia
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: htt
on,
http://qa.php.net/.
Ilia Alshanetsky
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
While anything would be better then the current solution I wonder is perhaps
going the INI way is not the best idea due to the potential confusion. The
fellow who supplies the ini files with browser information also has a csv
file with the very same data that is much easier to parse.
Ilia
On A
On August 4, 2004 11:16 am, Dave wrote:
> I think his point was that the hash is calculated as the file is being
> uploaded, which saves having to read the whole file a second time after
> uploading is finished. For big files, and repetitious uploading, this
> could probably save on the CPU cycles
-1 it seems somewhat redundant given that this signature can be easily
generated via a single function call, md5_file() or sha1_file().
Ilia
On August 4, 2004 10:56 am, David Santinoli wrote:
> Hi,
> I'm submitting a patch to perform "on the fly" MD5/SHA1 digest
> calculation of a file uploade
and others that have shown interest in the addition of this
> feature. For them, we'd just be placing a BIG trap they can and most
> probably will fall into.
>
> Zeev
>
> At 21:08 30/07/2004, Andi Gutmans wrote:
> >At 01:53 PM 7/30/2004 -0400, Ilia Alshanetsky wrote:
>
On July 30, 2004 02:25 pm, you wrote:
> At 21:19 30/07/2004, Ilia Alshanetsky wrote:
> >It seemed to me like people have raised numerous valid argument and have
> > even gone as far as to back them up with examples. If you need more of
> > those, then surely the supporters of
On July 30, 2004 02:08 pm, Andi Gutmans wrote:
> I'm not saying that. I'm just saying that you should not only think of
> yourself as a user but of everyone (i.e. make sure you put yourself in the
> shoes of others and try and base your position on that). If you think the
> majority of PHP users sh
On July 30, 2004 01:38 pm, Andi Gutmans wrote:
> a) Most of the OOP functionality was requested by a huge amount of PHP
> developers I've talked to.
I cannot comment on that as I can't hardly comment on the people you spoke
with. What I personally heard about OO primary request from developers th
On July 30, 2004 01:11 pm, Andi Gutmans wrote:
> Secondly, I just don't understand what the sudden necessity for the goto
> construct is when over the years we have barely ever had a PHP developer
> asking for it.
That can be said for virtually any new functionality that was added to PHP.
Looking
On July 30, 2004 02:43 am, Andi Gutmans wrote:
> At 04:55 PM 7/29/2004 -0700, Sara Golemon wrote:
> I think there are only two cases where goto is really interesting:
> a) Error handling.
> b) Auto-generating code or compiler compilers (Sterling mentioned these
> two).
c) Anywhere recursive functi
On July 29, 2004 09:13 pm, Andrey Hristov wrote:
> Ok, I surrender. Go for it :)
> I will pray and let God save me from ever maintaining spaghetti goto code
> :)
Andrey,
Well, you already have a list of goto enabled languages to avoid, what's one
more? :-)
Ilia
--
PHP Internals - PHP Runtime
On July 29, 2004 08:32 pm, Andrey Hristov wrote:
> Ilia, my idea is that goto brings problems in most cases and I kind of
> saving my donkey (and maybe the donkeys of other people) of some royal pain
> when we are pushed to support badly written _legacy_ code.
Andrey,
Just ask and I'll show you o
On July 29, 2004 05:25 pm, Timm Friebe wrote:
> In the five or six year's I've been programming PHP, I haven't ever felt
> the need to have "goto". Neither have I seen a newsgroup posting related
> to it in the two years or so I followed the German PHP newsgroup,
> de.comp.lang.php.
I must admit t
Andrey,
Here are some more programming languages you may wish to discredit for their
goto support.
Fortran,
C#,
Cobol,
Ada
Ilia
On July 29, 2004 08:10 pm, Andrey Hristov wrote:
> Robert Cummings wrote:
> > On Thu, 2004-07-29 at 17:25, Timm Friebe wrote:
> >>On Thu, 2004-07-29 at 04:12, Sara G
On July 29, 2004 08:00 pm, Andrey Hristov wrote:
> Is the average Joe going to write parsers in the everydays work? Probably
> not. But give him the power of goto and (s)he is going to shoot him/her in
> the legs, in the heart, in the head. And even not only himself because
> (s)he will create a le
PHP is a not a type strict language, far from it and it is unlikely it'll ever
be such. It is also a not pure OOP language and I very much doubt it'll ever
be one.
While GOTO can be abused, so can any other language feature, such as OOP, or
the ability to include remote files. If we add this fea
Goto is an extremely useful for parsers and makes life much easier when
dealing with complex error handling situations.
+1
Ilia
On July 28, 2004 10:12 pm, Sara Golemon wrote:
> I wrote up a patch for implementing gotos in php scripts a couple months
> ago as an exercise in working with the Zend
you in a dark alley with a surprise :)
>
> Andi
>
> At 01:09 PM 7/23/2004 -0700, Sterling Hughes wrote:
> >dooalocaaa, damnit
> >
> >On Fri, 23 Jul 2004 09:54:27 -0700, Andi Gutmans <[EMAIL PROTECTED]> w
On July 23, 2004 12:40 pm, you wrote:
> At 11:54 AM 7/23/2004 -0400, Ilia Alshanetsky wrote:
> >On July 23, 2004 11:42 am, Andi Gutmans wrote:
> > > Why do we need one extra byte?
> >
> >We do not.
> >
> > > Anyway, the question is if we should retu
On July 23, 2004 11:42 am, Andi Gutmans wrote:
> Why do we need one extra byte?
We do not.
> Anyway, the question is if we should return to alloca() or not. I am
> slightly in favor but don't feel very strongly about it.
Perhaps we could try a combination of the two, to ensure that no script is
On July 16, 2004 12:41 pm, Thies C. Arntzen wrote:
> php has no real concept for out-of-memory situations (stack or real)
> - nor do we catch infinite (nor too deep) recursions. allowing for
> "deeper" recursion doesn't really fix anything. so, i think we should
> either come up with a real soluti
efinitely improve your point if the
> performance penalty show in that case.
>
> At 05:58 PM 7/16/2004 +0200, Thies C. Arntzen wrote:
> >On Fri, 16 Jul 2004 08:39:21 -0400, Ilia Alshanetsky <[EMAIL PROTECTED]>
wrote:
> > > Oops mail client assign the message to the wrong
On July 16, 2004 11:58 am, Thies C. Arntzen wrote:
> hey ilia,
>
> here's another one of my meaningess, synthetic benchmarks (this is how
> the CreatorsOfPHP(tm) would call them)
>
> ackermann(8) (source on request - highly recursive)
Recursive functions in PHP are inherently dangerous as without
On June 24, 2004 09:34 am, [EMAIL PROTECTED] wrote:
> Ilia Alshanetsky <[EMAIL PROTECTED]> writes:
> > Just applying the patch as you've suggested will cause problems as the
> > PHP tree have some fixes inside libsqlite that were not yet (or never
> > even submitte
Just applying the patch as you've suggested will cause problems as the PHP
tree have some fixes inside libsqlite that were not yet (or never even
submitted) added to the external library.
Ilia
On June 21, 2004 02:52 pm, [EMAIL PROTECTED] wrote:
> This is a resend of the following message but wi
On June 16, 2004 12:15 pm, Ard Biesheuvel wrote:
> Ilia Alshanetsky wrote:
> > PHP5/Interbase: too many arguments passed to some functions.
>
> The function in question alloca()tes a 4 pointers times the number of
> args which is kept in an unsigned short. This means the allocat
>
> Andi
>
> At 12:10 PM 6/14/2004 -0400, Ilia Alshanetsky wrote:
> >Virtually all current uses involve some form of user input, which means
> > that the user can exploit the problem. When bar[2048] is used to create a
> > buffer of a certain known size that never change
Do you have an example script that can be used to reproduce the supposed
memory access violation?
Ilia
On June 14, 2004 01:51 pm, Alexander Valyalkin wrote:
> Here is patch for basename() function, which prevents possible
> memory access violation:
>
> =cut=
> --- string.cThu
Virtually all current uses involve some form of user input, which means that
the user can exploit the problem. When bar[2048] is used to create a buffer
of a certain known size that never change, with alloca a buffer of undermined
size is created in most cases.
The only 'safe' way to use the fu
There is a rather nasty crash possible in PHP due to the usage of the alloca()
function as can be demonstrated by bug #28064.
Simpler bug replication case:
php -r ' $a = str_repeat("a", 1024 * 1024 * 6); defined($a); '
The problem is the result of missing checks to determine if alloca() had
work
Read your memcpy manpages
"The memcpy() function copies n bytes from memory area src to memory
area dest. The memory areas may not overlap."
Ilia
On June 11, 2004 10:50 am, Alexander Valyalkin wrote:
> Read it:
> void *memmove(void *s1, const void *s2, size_t n);
> If s1 and s2 overlap,
801 - 900 of 1081 matches
Mail list logo
