Hello all,
I am working on ARM server performance tuning, and I have been playing
around a bit with the various executor modes and zend_vm_gen.php.
As it turns out (scroll down for numbers), the GOTO executor is much
faster than the default CALL executor on ARM, partly due to fewer branch
mi
On 3 March 2013 12:36, Hannes Magnusson wrote:
> On Sun, Mar 3, 2013 at 3:25 AM, Ard Biesheuvel
> wrote:
>> I am fine using the new account. If there is a need to merge the
>> karma, please do so but I think the new account has all the karma I
>> need.
>
> You can&#
On 3 March 2013 18:08, Hannes Magnusson wrote:
> If you'd like to change your username to your new one we can delete
> your old account and merge your karma (if there is any difference) to
> your new accounts and delete the old account..
>
I am fine using the new account. If there is a need to m
On 3 March 2013 07:48, Hannes Magnusson wrote:
> On Thu, Jan 17, 2013 at 8:18 AM, PHP Group wrote:
>> rasmus approved ardbiesheuvel account request \o/
>>
>
> Are you a different guy from abies (with an @ewi.tudelft.nl address)?
> Credited as the author of Firebird/InterBase driver for PDO & Inte
Hey all,
In commit http://git.php.net/?p=php-src.git;a=commitdiff;h=afe98b78
I just noticed two instances of the following:
ctxt->options -= XML_PARSE_DTDLOAD;
Shouldn't that be
ctxt->options &= ~XML_PARSE_DTDLOAD;
or am I missing something?
--
Ard.
--
PHP Internals - PHP Runtime Developme
is area, I will not
pursue this any further.
Are there any other optimizations involving inline assembler that you
implemented for PHP? I would like to review them to see if I need to add
an ARM version.
Cheers,
Ard.
>From 16f61b05b3911c91b52c5eff66c2274d5a7c817f Mon Sep 17 00:00
two additional CPU instructions.
> However CPU branch predictor should make this advantage unimportant.
>
> Thanks. Dmitry.
>
>
> On Fri, Jan 18, 2013 at 10:08 PM, Ard Biesheuvel
> wrote:
>>
>> Hello,
>>
>> Again, apologies for prematurely declaring someone
1m28.124s
user1m28.082s
sys 0m0.004s
$ time php -r 'for ($i = 0; $i < 0x7fff; $i += 3);'
real0m20.561s
user0m20.545s
sys 0m0.004s
$ time php -r 'for ($i = 0x7fff; $i >= 0; $i -= 3);'
real0m20.524s
user0m20.509s
sys 0m0.004s
&
12:25 PM, Ard Biesheuvel wrote:
Hello all,
As I indicated yesterday, I am looking into PHP performance when running
on ARM, and while doing that, I ran into the following code in
Zend/zend_operators.h.
For 32-bit x86, we have the following assembler code to do a 'fast'
increment (%0
Hello all,
As I indicated yesterday, I am looking into PHP performance when running
on ARM, and while doing that, I ran into the following code in
Zend/zend_operators.h.
For 32-bit x86, we have the following assembler code to do a 'fast'
increment (%0 is a zval*):
incl (%0)
On 17 January 2013 16:22, Rasmus Lerdorf wrote:
> Welcome back Ard. Looks good to me, but I don't have an ARM box to test
Thanks!
I have done some manual testing on the corner cases, both on the 64-bit
ARMv8 emulator and a 32-bit TI Beaglebone, and have also run the test
cases in the Zend/ folde
Submitting performance tweaks specific to ARM platforms (both 32 and 64 bit)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
. |
+--+
| Authors: Sascha Schumann |
- | Ard Biesheuvel |
+ | Ard Biesheuvel
Hello all,
Some of the senior citizens in this community may remember me.
I used to be involved in PHP development (and went to some
conferences) in 2002-2005.
I am now working for Linaro (www.linaro.org), trying to engineer
the best LAMP stack possible for ARM servers (32 and 64 bit).
I would li
Guys,
Sorry for the late reply. As you might have guessed already, PHP is not
a high priority for me at the moment.
First of all, you will probably remember that I was not completely
satisfied with the direction set out for PDO, the reason being that the
chosen model for PDO doesn't map real
Ard Biesheuvel wrote:
Does anyone know if the build system on UNIX ever contained a test for
the availability of strptime() ? The Interbase module uses the
HAVE_STRPTIME macro, but it never gets #defined. Would anyone object if
I add such a test?
Replying to myself:
apparently it *does
Hi,
Trying to fix an issue with the interbase extension.
Does anyone know if the build system on UNIX ever contained a test for
the availability of strptime() ? The Interbase module uses the
HAVE_STRPTIME macro, but it never gets #defined. Would anyone object if
I add such a test?
Regards,
Joe Orton wrote:
Testing "length >= LONG_MAX" where length is an int is always false, and
gcc gives a warning for it. Perhaps something like this was intended?
On 64-bit it is always false, however on 32-bit 'length == LONG_MAX' can
be true. That's probably why noone caught the warning so far, as
Some questions that came to mind while working on PDO/Firebird:
- why can't stmt_get_col() return a zval directly?
- why is there no PDO_PARAM_DOUBLE?
--
Ard
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Wez Furlong wrote:
5.1 beta is scheduled for March 1st, and we'll follow that with the
usual RC process. I think you have a little bit of time; the changes
OK.
For instance (these issues have been pointed out by me before):
- Firebird has transactions over multiple connections [no JOINs between
da
Hi everyone, long time no post!
Wow, a lot has happened to PDO while I was looking the other way for a
minute. I hope I will soon find the time to bring PDO_FIREBIRD up to
date with all the recent changes.
What would be a reasonable deadline for this (in relation to 5.1) ?
Lester Caine wrote:
>
Joe Orton wrote:
The DVAL_TO_LVAL macro is quite weird, I'm not sure exactly what it's
supposed to be doing but it probably isn't doing it. If the integral
part of d is outside the range of a long, the conversion has undefined
behaviour by the C99 standard; an explicit cast makes no difference
AFAI
Joe Orton wrote:
The DVAL_TO_LVAL macro is quite weird, I'm not sure exactly what it's
supposed to be doing but it probably isn't doing it. If the integral
part of d is outside the range of a long, the conversion has undefined
behaviour by the C99 standard; an explicit cast makes no difference
AFAI
This is a possible fix for #28167
Anyone care to have a look ?
--
Ard
Index: zend_builtin_functions.c
===
RCS file: /repository/ZendEngine2/zend_builtin_functions.c,v
retrieving revision 1.237
diff -u -r1.237 zend_builtin_functions.c
This is a possible fix for #28167
Anyone care to have a look ?
--
Ard
Index: zend_builtin_functions.c
===
RCS file: /repository/ZendEngine2/zend_builtin_functions.c,v
retrieving revision 1.237
diff -u -r1.237 zend_builtin_functions.c
Is the fact that the following code works intentional ?
class S {
function func() {
A::meth();
}
}
class A {
private $bar;
function meth() {
$this->bar="bar";
}
function func() {
S::func();
The problem with ints and longs is not their sizes, but the fact that
people use them interchangeably, their sizes being equal coincidentally
on 32-bit architectures.
Most of the bugs occur when pointers to these variables are passed as
arguments to variadic functions like zend_parse_parameters
Would anyone with Zend karma care to commit this ?
--
Ard
Index: zend_builtin_functions.c
===
RCS file: /repository/ZendEngine2/zend_builtin_functions.c,v
retrieving revision 1.237
diff -u -r1.237 zend_builtin_functions.c
--- zend_bui
Sara Golemon wrote:
iirc, Linux treats both int and long as 64bit datatypes so it'd be a
non-issue there. The concern is platforms which treat int and long as
different sizes. Watch your configure output for:
Actually, (un)signed ints are 32-bit on all 64-bit platforms I know of
(Linux/[Free]BSD
Hartmut Holzgraefe wrote:
Adam Maccabee Trachtenberg wrote:
Logically, it would probably be best to return 0 because that's where
the first empty string occurs.
this is strrchr(), not strchr() ;)
Actually it's strrpos(), not str[r]chr() [look at Alexander's code],
which _has_ been rewritten in
Alexander Valyalkin wrote:
> Today I've revised strrchr() function in PHP4.3.7 sources.
> It wasn't binary-safe. For example:
... which is probably why it has already been completely rewritten in PHP 5.
--
Ard
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www
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 allocated memory
can at most be 1M.
While this seems a lot to allocate on the stack,
Alexander Valyalkin wrote:
On Wed, 16 Jun 2004 12:03:36 +0200, Ard Biesheuvel <[EMAIL PROTECTED]> wrote:
Have you tested my initial re-implementation of crc32() on 64-bit
architectures?
No, but I don't have to:
register unsigned long int crc = ~0ul;
... so crc = 0x
Lester Caine wrote:
On the other hand, if code IS working stably then it may be better to
leave it alone. I'm not saying don't tidy up code, but ALL the tests
against a change need to be in place before a change is applied to the
live code, and in some cases it is worth remembering that PHP *IS*
Ilia Alshanetsky wrote:
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 following two fragments will lead to virtually ide
Alexander Valyalkin wrote:
:) Are you sure? I'm not. Look on declaration of [nr] variable:
int nr;
And answer, please, which value will be assigned to nr, if length of
a string will be greater than 0x7fff on 32-bit architecture?
The funny thing is that in this case, it doesn't matter if 'nr' is
Alexander Valyalkin wrote:
1) Automatic initialization of crc32tab[] at first call.
So, the file crc32.h with definition of this tab is not
nessesary any more now.
First of all, crc32tab is no longer in the .text segment, so it will not
be shared between forked processes, taking more memory
Hi,
Are we going to keep supporting the old build system now we don't need
it anymore to generate the Windows binaries.
As far as Interbase is concerned, it needs to be either updated or
removed, and personally I prefer the latter.
--
Ard
--
PHP Internals - PHP Runtime Development Mailing List
Derick Rethans wrote:
Erm, we're very close to release candidate 3, IMO it's not a really good
idea to add new features now.
I understand, and I agree.
However, this file is not actually part of the extension itself, and
it's not built as part of the PHP engine. If you want to use it, you
have to b
Hi all,
is there a specific reason why nested blocks in switch statements are
not supported ? It can be very useful if you want to jump into the
middle of the first iteration of a loop (like fetching rows from a
result set where the first row might or might not be already present)
Eg.
switch ($
Hello,
Recently, I've changed ibase_query() to return the number of affected
rows, if appropriate. This works like a charm in all cases except the
one where the query is successful but no rows are returned.
Returning int(0) in this case would evaluate to 'false' indicating
failure. This would br
George Schlossnagle wrote:
I don't get this question, can someone reiterate the full context of it
for me?
For instance, if you prepare the statement
"SELECT * FROM WHERE id=?"
Firebird can figure out the type of the 'id' param, meaning you don't
have to bind it to a certain type, whereas the em
Wez Furlong wrote:
PDO doen't separate the concept of a session or environment from a connection
to a database. This is perhaps where you are finding the fault. The thing is
that not all databases work in this way, so we've gone for the more portable
approach again.
I see that, but my point is th
Wez Furlong wrote:
PDO tries (a bit) to keep things portable: if it's a method of the PDO or
PDOStatement classes, then you can be reasonably sure it's supported for a
given driver. That doesn't mean that I want to exclude all non-portable
behaviour, I just want to make sure that we don't overload
try to squeeze everything into PDO, but we
should at least make the API leave some room for it.
--
Ard
--Wez.
-Original Message-
From: Ard Biesheuvel [mailto:[EMAIL PROTECTED]
Sent: 22 May 2004 16:39
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
Guys,
I saw the alpha of PDO on pecl. I was wondering if we could discuss the
design of it a bit more before putting too much work into it.
In particular, the way transactions are represented is not very
practical. Generally, databases that support transactions will support
multiple concurrent
Timm Friebe wrote:
Hello,
are we off one here?
$ php-dev -r 'var_dump(-2147483648);'
float(-2147483648)
$ php-dev -r 'var_dump(-2147483647 -1);'
int(-2147483648)
No, this is caused by the way the parser works.
The unary minus is parsed separately from the number. I've reported this
to Andi a while
Hi,
As default values for type-hinted parameters are now pointless, should
we still allow them ?
--
Ard
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Timm Friebe wrote:
Or, replying to myself, simply use convert_scalar_to_number() from
Zend/zend_operators.c which (AFAIS) does pretty much the same. The
testcase I wrote for this (attached) is passed here.
I think that should do the trick ...
Ard, do you use sybase_ct? If so, could you verify it wo
Hi Timm,
I have an old Alpha PWS433 running FreeBSD which I use for this kind of
stuff.
If so, what does this print?
--
#define LONG_MAX 2147483647L
#define LONG_MIN (- LONG_MAX - 1)
Use this for portability
#define LONG_MIN
Timm Friebe wrote:
+ case 3:
+ /* This signals we have an integer datatype, but we need to convert to double if we
+ * overflow.
*/
convert_to_double(&result->data[i][j]);
+ if (Z_DVAL(result->data[i][j]) >= LONG_MIN && Z_DVAL(result->data[i][j]) <= LONG_MAX) {
Hello,
As the current Interbase extension support for Interbase version 5 and
lower is probably broken, and certainly untested, I'm considering
removing it for PHP 5 final. [Interbase 6 was released in '99 or 2000,
this is the version Firebird SQL is based on]
I'm going to post this on the PHP
Ha Jochem,
Jochem Maas wrote:
I have discovered behaviour which I imagine is not intended, name
referencing $this in a static method that is called from a from the
method of an instantiated. (see test code below.)
error_reporting(E_ALL & E_STRICT);
I'm sure you mean E_ALL | E_STRICT here ...
C
Lester Caine wrote:
An interesting little question has pooped up.
How big is an integer?
Firebird uses BIGINT or INT_64 for generator values, and the new
ibase_gen_id in PHP5 returns that value as an integer.
Has any thought been given to managing 64bit field values in PHP5?
Actually, this 'ti
Exceptions in languages like Java are used explicitly to catch fatal
errors, not to catch basic errors. Converting warnings to exceptions
would change the meaning of a warning from something which is nice for
development, or logging purposes, but handled by your control flow, into
an unrecover
Does anyone mind if I change the prototypes of
ibase_user_add|modify|delete() to use service resources instead of the
current db/dba_name/dba_password style prototypes ?
I would like to do it before PHP 5.0.0 because it's a BC break.
--
Ard
--
PHP Internals - PHP Runtime Development Mailing Lis
Lester Caine wrote:
So it IS something that I will have to take account of when I start
looking at moving the interbase module to a firebird native version. If
the interbase module accesses the OO-style API. If it does not, then I
presume that it may be advantageous to handle any required conver
Lester Caine wrote:
The current php manual has hundreds of functions with underscore in the
name. Are these all going to be replaced? In which case ALL existing
script has to be re-written?
No, studly caps have been adopted as a standard only for method names in
the OO-style API, not for the pro
Andi Gutmans wrote:
Can you run this by Sascha <[EMAIL PROTECTED]> who wrote this code?
I sent him a message but he never responded.
--
Ard
Thanks,
Andi
At 04:50 PM 3/9/2004 +0100, Ard Biesheuvel wrote:
This code fails on 64-bit archs because it relies on the accuracy of a
double
Jan Lehnardt wrote:
this was proposed several times already and probably agreed on, too.
All it takes is a developer, who is _that_ annoyed to implement
something like this.
Everything is in CVS, send in patches, not enough karma is not a
valid excuse :)
Have a look at this patch. Maybe it will wo
Wez Furlong wrote:
as a simple optimization, can we disallow requests with a single-word reason
from ever reaching the account request system?
Likewise, we can also do the same for the requests containing the word
"learn".
What about a little quiz (a couple of questions about CVS or about PHP)
to
This code fails on 64-bit archs because it relies on the accuracy of a
double to be sufficient to represent LONG_MAX. The patch adresses it by
checking for overflow by reversing the calculation instead of casting to
a double and back to long.
#include "build/php5-cvs/Zend/zend_multiply.h"
#def
While http://www.php.net/zend-engine-2.php claims the following
'Like constructors, parent destructors will not be called
implicitly by the engine. In order to run a parent destructor,
one would have to explicitly call parent::__destruct() in the
destructor body.
th
This script crashes with the latest HEAD.
I don't know if it is something that did work at an earlier time.
class Image
{
const RESOURCE_FORMAT = ResourceFormat::IMG;
}
print_r(constant('Image::RESOURCE_FORMAT'));
?>
--
Ard
--
PHP Internals - PHP Runtime Development Mailing List
To unsubsc
Jan Lehnardt wrote:
your patch contains more than just the new testcase.
That's probably the reason, why it wasn't committed
yet.
That's why it says '... and some wordsize stuff' in the subject line.
--
Ard
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.
Wrong list, sorry
Original Message
Subject: PATCH: operator precedence test and some wordsize stuff
Date: Wed, 25 Feb 2004 12:03:27 +0100
From: [EMAIL PROTECTED] (Ard Biesheuvel)
To: [EMAIL PROTECTED]
Newsgroups: php.zend-engine.cvs
Followup-To: php.dev
--
Ard
Index: Zend
Thanks, this why i had a SEGV too. And i found a problem in the way the
engine destructs and frees objects during shutdown. Please try again it
should be fixed right now.
It works now.
--
Ard
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.ph
Marcus Boerger wrote:
Hello Ard,
on the first sight it looks pretty much as if you havn't updated your build
tree completley. Please check that ext/spl, ext/sqlite and Zend are up to
date. Because for me it works pretty well. However i think this may not be
your problem since looking at the backt
Marcus Boerger wrote:
Hello Ard,
on the first sight it looks pretty much as if you havn't updated your build
tree completley. Please check that ext/spl, ext/sqlite and Zend are up to
date. Because for me it works pretty well. However i think this may not be
your problem since looking at the backtr
#0 0x081b81ed in _zend_is_inconsistent (ht=0x5a5a5a5a, file=0x821d580
"/home/abies/build/php5-cvs/Zend/zend_hash.c", line=504)
at /home/abies/build/php5-cvs/Zend/zend_hash.c:53
#1 0x081b99b2 in zend_hash_destroy (ht=0x5a5a5a5a) at
/home/abies/build/php5-cvs/Zend/zend_hash.c:504
#2 0x08090c
Currently, ext/sqlite/tests/sqlite_oo_031.phpt crashes after completion
of the script. If I unset($menu_iterator) first, the crash disappears.
--
Ard
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Jani Taskinen wrote:
sniper Thu Feb 19 22:05:43 2004 EDT
Modified files:
/php-src/ext/oci8 oci8.c
Log:
Only use Z_TYPE* with zvals..
-static oci_descriptor *oci_new_desc(int type,oci_connection *connection)
+static oci_descriptor *oci_new_desc(int type, oci_connection
Marcus Boerger wrote:
as i said before there is a reason for that: I played a long time with
exceptions until they became what they are right now. And and attempt
to increase the visibility of one of its members can be used to make it
SEGV. So i don't want more visibility. Also where is the reason
Hans Lellelid wrote:
Personally as PHP developer (as opposed to internals developer) I am not
in favor of having an interface, because I want to know that
try {
// ...
} catch (Exception $e) {
// ...
}
will catch *all* exceptions thrown by any libraries I choose to use,
etc. Mixing the inte
Ard, if the Exception class is not the base class of all exceptions(catch
all), it's very difficult to emulate "finally"(You must know every
exception that may be thrown inside the try block, and sometimes you
don't).
Of course, I was just stating that 'finally' != 'catch (...)', while
some of the
I understand mostly everything you say except for why there's any
motivation to introduce more headaches in the form of a new Throwable
interface, forcing people to become acquainted with interfaces before
they can throw an exception. Under the assumption that we want to
Not true, because the
George Schlossnagle wrote:
On Feb 13, 2004, at 11:35 AM, Adam Maccabee Trachtenberg wrote:
Andi's point, I believe, is that otherwise we'll need to add a
"finally" keyword to make sure some random extension doesn't throw
some random undocumented exception that you could miss. And I agree
with him
Anyway, the problem in PHP is one of implementation. The reason it has
problems is because dl loads/unloads for every request, rather than
loading and leave loaded like all other languages.
I fixed a similar issue recently in the interbase module. I ended up
NULLing the dlopen() handle in the m
Hi Paul,
Why are you comparing, copying and converting each array element twice ?
There should be a more elegant way to do this.
--
Ard
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Ilia Alshanetsky wrote:
Majority of PHP application and hence users do not require this extension.
Those who do, in most cases operate in an environment where they have full
control over their PHP configuration and thus will be able to enable this
extension on demand.
I agree with Ilia.
-1
--
Guys,
Any chance this will make it into RC1 ??
--
Ard
Index: interbase.c
===
RCS file: /repository/php-src/ext/interbase/interbase.c,v
retrieving revision 1.194
diff -u -r1.194 interbase.c
--- interbase.c 21 Jan 2004 10:22:04 -
Never mind!
I just had to rebuild resolv.lib instead of using the one in the archive.
--
Ard
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Guys,
This is what I get when I try to build on VC6. It appears that the
/nodefaultlib:libcmt prevents the linker from pulling in libcmt because
resolv.lib references it. The resolv.lib is the one from the
php_build.zip archive.
Do I need another resolv.lib that is linked to the right C-lib ??
Hi guys,
When building HEAD on VC6 with the new build system, the linker fails
because the symbols _pctype and ___mb_cur_max are not defined. These are
defined in libcmt, which is excluded explicitly from the link stage.
If I remove the /nodefaultlib:libcmt directive, the build succeeds with
a
Changing the recommended setting of enable_dl is a first step.
I disagree. Set enable_dl Off in the recommanded php.ini will make it
disabled in many situations. This is not something good. But this
discussions sounds like 'Do we have to educate endusers?'. Wez sample
usage is the perfect example
Wez Furlong wrote:
I agree; we can't deprecate dl().
There are some very common legitimate cases where it is really
useful, such as loading extensions that are not often needed into
a CGI (you don't want those in php.ini as they can slow down
your process startup).
I agree, but perhaps we should m
dl() is evil and should be deprecated. Actually that reminds me to add
an E_STRICT about it. Shared libraries should only be loaded via php.ini.
How about setting 'enable_dl' to 'Off' in php.ini-recommended ?
--
Ard
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: h
I don't know if we should get into this. Do we *really* care if we crash
on exit?
Are you serious ?? Of course we care about segfaults, don't we, even if
it's 'only' on exit ??
We are talking about MSHUTDOWN not RSHUTDOWN here. It's not an
Depends if you use dl() or load from php.ini. If loade
I've come up with a rather ugly workaround for this bug, but it does
work and it only touches interbase.c.
It basically works in the following way:
- the module refuses to be loaded by dl() [MODULE_TEMPORARY], so
only loading from php.ini is allowed [MODULE_PERSISTENT],
- the module NULLs its dlo
Hello group,
I'm looking for a way to fix http://bugs.php.net/26968. This bug is
caused by the underlying client .so using atexit() to register a cleanup
function. As the library is unloaded before process shutdown, the
atexit() stack no longer contains a valid reference when it is called,
res
> Here is the code in exec.c,
> ---
> line# 586: pid_t child, wait_pid;
> line# 587:
> line# 588: child = (pid_t)rsrc->ptr;
[EMAIL PROTECTED] wrote:
rsrc->ptr is a generic use "bucket". Generally it's meant to hold a
pointer to some data. In
Ilia Alshanetsky wrote:
iliaa Mon Dec 1 18:21:26 2003 EDT
Modified files: (Branch: PHP_4_3)
/php-src/ext/standard string.c
Log:
MFH: Optimize substr_replace
Which bug does this fix ?
--
Ard
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: ht
Nicol At Aokp Dot Ru wrote:
From: nicol at aokp dot ru
Operating system: FreeBSD 4.9
PHP version: 4.3.4
PHP Bug Type: Compile Failure
Bug description: php with Interbase extention under FreeBSD must be linked with
-lcrypt
Description:
php 4.3.4/5.0.0.Beta2 same b
Steph wrote:
... except that INT_PTR is 64-bit on Win64, and int is not.
yeah, I just found that too :)
This means that php-src is currently correct for all architectures but fcgi
src is not. So what's the best line of attack here?
What about
#define ssize_t INT_PTR
for Win{32|64} ??
--
Ard
-
Steph,
Windows - uniquely - uses the definition SSIZE_T (type: INT_PTR) - note
that ssize_t isn't the same thing as SSIZE_T, anywhere - but if I go that
route for ssize_t definition (as I already tried to do) we end up with the
fcgi redefinition to int anyway.
Basically all I'm doing here is goin
Steph wrote:
Works with everything. (phew!)
Are you sure this will work on Win64 ?
I think sizeof(ssize_t) is supposed to match the native pointer size.
--
Ard
Index: main/config.w32.h
===
Works with everything. (phew!)
You might wanna use long instead of int here, as sizeof(ssize_t) is
supposed to match the native pointer size.
--
Ard
Index: main/config.w32.h
=
Do any of you think that old bugs that were mistakenly given the status
'Closed' should be re-labelled 'Bogus' ?
[there are quite a number of Interbase bugs that weren't actually bugs,
but were given the status 'Closed']
--
Ard
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscr
Alexey Trunyov wrote:
Why shouldn't ibase_errcode() function get backported from HEAD to PHP_4
branch? It requires only minor changes, I did that and it works fine for
now.
I agree that it's a minor change, so backporting it would be trivial.
However, the PHP_4 branch is bug fixes only, and in m
After all this I guess I have to maintain my own PHP branch and hope for
PHP6 to address some of my issues. Or switch to another language at some
point, because a language to me is a tool, not a religion.
This is exactly the point. Why waste so much energy on deciding how to
spell out your array
1 - 100 of 135 matches
Mail list logo
