[PHP-DEV] [Spam 05.31] RE: [PHP-DEV] Inheriting from internal classes
Spam detection software, running on the system "jc.thebrainroom.net", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or block similar future email. If you have any questions, see the administrator of that system for details. Content preview: IIRC, we made FFI do this. Also, I believe one of the new dom extensions does it too. --Wez. > Content analysis details: (5.3 points, 5.0 required) pts rule name description -- -- 2.0 NEW_DOMAIN_EXTENSIONS BODY: Possible registry spammer 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay --- Begin Message --- IIRC, we made FFI do this. Also, I believe one of the new dom extensions does it too. --Wez. > -Original Message- > From: l0t3k [mailto:[EMAIL PROTECTED] > Sent: 14 May 2004 22:08 > To: [EMAIL PROTECTED] > Subject: [PHP-DEV] Inheriting from internal classes > > Wez and Marcus (and anyone else), > is there a way with the current CVS to permit subclassing > of internal, > overloaded classes without seg faulting ? or is this a known > problem. i ask > this based on my reading of the source for PDO. > > l0t3k > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > --- End Message --- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Inheriting from internal classes
Wez and Marcus (and anyone else), is there a way with the current CVS to permit subclassing of internal, overloaded classes without seg faulting ? or is this a known problem. i ask this based on my reading of the source for PDO. l0t3k -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hints resolution?
Hello Hans, Friday, May 14, 2004, 4:53:44 PM, you wrote: > Hi, > I just wanted to find out what the final resolution was on the typehints > discussion for RC3. I know that I (& others) will be sad to see typehints > disappear for optional parameters, but it seemed like there was a lot of > support for this from others on the list. > I didn't get a clear sense of "majority" one way or another, but it > sounded like Andi said that for PHP5RC3 there would be no more typehints > + null allowed. There was a majority on don't allow NULL by default (at least among the engine developers). And as there was no good idea that could also be implemented without sideeffects like creating problematic keywords we decided to disallow NULL for typehints and care for it after 5.0 if enough people request it and somone has a good idea for the syntax. > I just want to know if I should start stripping out typehints from > optional params in preparation for RC3. For PHP 5.0 that si definitively the way to go. regards marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php-src /ext/sybase_ct php_sybase_ct.c
Hi Internals, hi Timm,
On Sat, 2004-01-24 at 03:17, Timm Friebe wrote:
> @- Fixed bug #22403 "PHP crashes when executing a sql procedure without
> @ parameters" (Timm)
> @- Fixed memory leak in sybase_set_message_handler() (Timm)
> # Fixed bug with large numerics correctly (initial fix in r. 1.76 failed
> # for MAX_LONG + 1, for example)
>
>
> http://cvs.php.net/diff.php/php-src/ext/sybase_ct/php_sybase_ct.c?r1=1.88&r2=1.89&ty=u
[...]
> static int php_sybase_fetch_result_row (sybase_result *result, int numrows)
> @@ -1057,7 +1066,14 @@
> case 1:
> convert_to_long(&result->data[i][j]);
> break;
> -case 2:
> +case 2:
> + /* We also get numbers that are actually integers here due to the check on
> + * precision against > 9 (ranges are -1E10 to -1E9 and 1E9 to 1E10). As we
> + * cannot be sure that they "fit" into MIN_LONG <= x <= MAX_LONG, we call
> + * convert_to_double() on them. This is a small performance penalty, but
> + * ensures that "select 2147483648" will be a float and "select 2147483647"
> + * will be become an int.
> +*/
> convert_to_double(&result->data[i][j]);
> break;
>
> }
(reindented quote to better fit into email)
[...]
> @@ -1167,7 +1184,7 @@
> case CS_DECIMAL_TYPE:
> result->datafmt[i].maxlength =
> result->datafmt[i].precision + 3;
> /* numeric(10) vs numeric(10, 1) */
> - result->numerics[i] = (result->datafmt[i].scale == 0
> && result->datafmt[i].precision <= 10) ? 1 : 2;
> + result->numerics[i] = (result->datafmt[i].scale == 0
> && result->datafmt[i].precision <= 9) ? 1 : 2;
> break;
> default:
> result->datafmt[i].maxlength++;
This patch (committed with rev. 1.89 in ext/sybase_ct/php_sybase_ct.c)
introduces a behaviour I consider broken:
# select 2147483647
becomes an int because Sybase automatically converts the input into
an int (ints have precision 0 (or NULL).
# select 2147483648
becomes a float because Sybase convert this into a numeric(10,0),
that is a numeric with precision 10. This numeric then will be
converted into a float (because of the code in the second quote).
This seems to be good, but this only works because the input is being
autoconverted by Sybase into a suitable datatype. Autoconversion does,
however, not apply to table columns (as they already have a type). Thus,
the introduced decision (int or float depending on precision of type)
applies to all rows of a result.
Image a column of type numeric(10,0)¹. Insert a row with value 1. Select
it, and it will be converted into float(1) - the columns precision is
still 10.
One may now say, this is good, because you want one column be mapped to
just one datatype in the client application. I think, because of PHP's
loose typing, it'd be better to get an int as long as possible and only
get floats when values exceed MAX_INT. This would also meet the
description from above's comment.
Attached is a patch which adds this; it is also available at:
http://document-root.de/patch/float-vs-int-php_sybase_ct.c.diff
Feedback appreciated.
Regards,
-Alex
1] Of course, we're only talking about numerics with scale 0.
Index: ext/sybase_ct/php_sybase_ct.c
===
RCS file: /repository/php-src/ext/sybase_ct/php_sybase_ct.c,v
retrieving revision 1.93
diff -u -r1.93 php_sybase_ct.c
--- ext/sybase_ct/php_sybase_ct.c 16 Apr 2004 16:27:13 - 1.93
+++ ext/sybase_ct/php_sybase_ct.c 14 May 2004 15:27:12 -
@@ -1135,6 +1135,13 @@
* will be become an int.
*/
convert_to_double(&result->data[i][j]);
+
+ /* If the result is smaller than LONG_MAX, it would still fit into
+ * an int, so convert it.
+ */
+ if (result->data[i][j].value.dval <= (double)LONG_MAX) {
+ convert_to_long(&result->data[i][j]);
+ }
break;
}
}
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Type hints resolution?
Hi, I just wanted to find out what the final resolution was on the typehints discussion for RC3. I know that I (& others) will be sad to see typehints disappear for optional parameters, but it seemed like there was a lot of support for this from others on the list. I didn't get a clear sense of "majority" one way or another, but it sounded like Andi said that for PHP5RC3 there would be no more typehints + null allowed. I just want to know if I should start stripping out typehints from optional params in preparation for RC3. Thanks, Hans -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] PDO (was: SQLite API deficiency)
Hi, > i'll update the checkout on my server but you will have it through > PECL anyway in a week. I'll wait :-) > > Great. What are the initial backends that will be supported? SQLite, > > MySQL, PGSQL? > > SQLite and Oracle first. We're hoping that the exact two you mentioned > follow very shortly after puttin pdo into pecl. Good plan. I would follow that very shortly with MS SQL (which I don't use but should be supported for more corporate reasons) Cheerio, Marc. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
