> As for minimal ranges, I think they are quite outdated - there are not
> many 16-bit systems around anymore, so most ints would be 32-bit by now.
>
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227
Yeah, the choice to make long longer
Hi!
This is not exactly correct. I think what you meant to say, is "long
isn't the same size as a pointer on Windows".
I actually meant to say it's no longer than int, which makes this type
kind of pointless currently. Both behaviors conform C standards and I'm
sure there were reasons why Wi
On Fri, Jun 10, 2011 at 7:08 PM, John Crenshaw wrote:
>
>> ITYM PHP uses "long" which unfortunately isn't long on windows.
>>
>> --
>> Stanislav Malyshev, Software Architect
>> SugarCRM: http://www.sugarcrm.com/
>> (408)454-6900 ext. 227
>
> This is not exactly correct. I think what you meant to s
> ITYM PHP uses "long" which unfortunately isn't long on windows.
>
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227
This is not exactly correct. I think what you meant to say, is "long isn't the
same size as a pointer on Windows".
Lo
On Fri, 2011-06-10 at 17:52 +0100, Derick Rethans wrote:
> Yes, indeed. That was a typo. The original point still stands though.
> And IMO, this should be fixed in the Windows port so that on 64 bit
> processors, the PHP "int" type (the C "long" type) is actually 64 bits,
> just like almost any
On Fri, 10 Jun 2011, Stas Malyshev wrote:
> > I agree that that should be the same. But sadly, Windows uses a
> > different integer size model than almost everything else modern.
> > Where Linux and Mac and other unices use 8 bytes for an "int",
> > Windows uses 4 bytes
> > (http://en.wikipedi
Hi!
I agree that that should be the same. But sadly, Windows uses a
different integer size model than almost everything else modern.
Where Linux and Mac and other unices use 8 bytes for an "int", Windows
uses 4 bytes
(http://en.wikipedia.org/wiki/LP64#Specific_C-language_data_models).
Because P
Hey all,
Let me start by saying that this is merely an idea I'm trying to put
together and before doing so, I need to see who would be interested.
A short while ago, the Python community created something called "The
Python Core Mentorship Program" [1][2] which is essentially an attempt
to lower
On 10 June 2011 16:54, Pierre Joye wrote:
> The sad part is not that windows uses a consistent type size across
> architecture but that linux and gcc considers that a type could be
> whatever the architecture uses. Hence why stdint.h was introduced and
> should be used instead of the long/int.
>
hi,
On Fri, Jun 10, 2011 at 4:47 PM, Derick Rethans wrote:
> On Fri, 10 Jun 2011, Hannes Landeholm wrote:
>
>> What are the reasoning behind this? I think the PHP integer size
>> should be changed to always be 64 bit - independent of the platform. I
>> have stumbled on this annoying inconsistency
On Fri, 10 Jun 2011, Richard Riley wrote:
> Hannes Landeholm writes:
>
> *snip button*
>
> Could anyone suggest why the php groups in particular mark post mime types
> incorrectly in certain instances? I am seeing
>
> ,
> | Content-Type: multipart/alternative; boundary=20cf301d426efd027f04
On Fri, 10 Jun 2011, Hannes Landeholm wrote:
> What are the reasoning behind this? I think the PHP integer size
> should be changed to always be 64 bit - independent of the platform. I
> have stumbled on this annoying inconsistency several times the last
> month.
I agree that that should be th
Hannes Landeholm writes:
*snip button*
Could anyone suggest why the php groups in particular mark post mime types
incorrectly in certain instances? I am seeing
,
| Content-Type: multipart/alternative; boundary=20cf301d426efd027f04a55b14cc
`
when there is only a single text part. Its
On Fri, 10 Jun 2011 13:39:34 +0200, Johannes Schlüter
wrote:
On Fri, 2011-06-10 at 12:03 +0100, Keloran wrote:
As far as I can see there are very few extension that are really needed
in
the core, the main problem comes from distributions changing the methods
that PECL works or the core wor
Greetings.
One very important feature of PHP is its interoperability. This allows my
colleagues to work in both Windows, Ubuntu and OSX - developing the same
application. Details like the fact that PHP will replace forward slash with
backward slash automatically in windows is a great example of th
On Fri, Jun 10, 2011 at 12:50 PM, Lars Strojny wrote:
> Please change your tone.
+1!
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hey,
I've seen Kalle's patch for http://bugs.php.net/bug.php?id=52555.
It actually implements a http_response_code() function to export the
current HTTP response code from SAPI layer to PHP user land.
I'm suggesting to rename that function to get_http_response_code(),
and implement its sister : s
On 06/10/2011 06:31 AM, Karl Pflästerer wrote:
> Hi,
> some people (like me) still have to use Apache 1.3; I can't compile
> PHP-5.4 with Apache-1.3, because of a change in revision 305276.
Applied, thanks.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: h
On Fri, 2011-06-10 at 12:03 +0100, Keloran wrote:
> As far as I can see there are very few extension that are really needed in
> the core, the main problem comes from distributions changing the methods
> that PECL works or the core works
>
> e.g.
> Ubuntu you need to install the -dev version in or
Hi,
some people (like me) still have to use Apache 1.3; I can't compile
PHP-5.4 with Apache-1.3, because of a change in revision 305276.
svn diff -c305276 main/SAPI.h
Index: main/SAPI.h
===
--- main/SAPI.h (revision 305275)
+++ main/S
As far as I can see there are very few extension that are really needed in
the core, the main problem comes from distributions changing the methods
that PECL works or the core works
e.g.
Ubuntu you need to install the -dev version in order for extension to be
compiled/installed
Gentoo you need to
Am 10.06.11 11:20 schrieb "Reindl Harald" unter :
>let the api fuck in peace or you risk that the extension will not used
>in the future because you force all users to totally change their
>projects with
>the fear that 5 years later 3.0.0 breaks all baackward compatibility again
Please change you
On Fri, Jun 10, 2011 at 11:52 AM, Henry Hayes wrote:
> I would like to become a maintainer of PHP and do bug fixes from the bugs
> list.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Hi.
That sounds great, however we don't
On Fri, 10 Jun 2011 11:29:44 +0200, Pierre Joye wrote:
> On Thu, Jun 9, 2011 at 8:11 PM, Michael Wallner wrote:
>
>> I started the rewrite of the extension, because it had one really big
>> drawback, namely that message bodies where implemented as memory chunk
>> instead of streams. The next ma
I would like to become a maintainer of PHP and do bug fixes from the bugs list.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Thu, Jun 9, 2011 at 8:11 PM, Michael Wallner wrote:
> I started the rewrite of the extension, because it had one really big
> drawback, namely that message bodies where implemented as memory chunk
> instead of streams. The next major headache caused the confusion which
> the HttpResponse clas
On 9 Jun 2011 20:11, "Michael Wallner" wrote:
> I started the rewrite of the extension, because it had one really big
> drawback, namely that message bodies where implemented as memory chunk
> instead of streams. The next major headache caused the confusion which
> the HttpResponse class was resp
Am 09.06.2011 20:11, schrieb Michael Wallner:
> In the past many developers did not feel comfy enough with the pecl_http
> extension. It had been proposed for inclusion in the core distribution
> for a few times, but people always had doubts about the API etc.
i do not understand why
> Anothe
28 matches
Mail list logo
