This seems trivial enough that there's no reason not to fold it into PHP5.
I do have a couple questions though:
1) What is the expected format of the date field? RFC822 format?
2) Would it make sense to pass an epoch timevalue to imap_append() and have
the function internally convert it to the a
> These unions would only be in the calling code, where they can be type
> specific, but I don't like this solution, too.
>
> But what's the best way then? Changing the casts from void** to void*?
> Compile with -fno-strict-aliasing?
The warning is emitted because, when compiling zend_hash_find(),
I'm developing (and to a large extent, already developed) an extension for use with
'gda' (Gnome Data Access library - www.gnome-db.org), a fully featured Database
Abstration-Layer. I would appreciate this being considered for addition to PHP at some
stage. Thank you.
--
PHP Internals - PHP Ru
A "make install" of the current 4.3 branch installs a broken phpize:
/usr/local/bin/phpize: line 1: /usr/local/lib/php/build/shtool: Permission denied
/usr/local/bin/phpize: line 61: -f: command not found
ls -l /usr/local/lib/php/build/shtool
-rw-r--r--1 root root36075 Aug 26 19:
Translating into french the pear's doc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hello group,
After having spent some time digging into the origin of the
strict-aliasing warnings when compiling with GCC 3.3 (brought about by
Stefan Roehrich's post a couple of days ago), I came up with a couple of
things that might be of interest in the development of PHP.
First of all, GCC
Hello internals,
The following code:
bla;
}
}
$o = new b;
print_r($o)
?>
results in two properties which is wrong:
b Object
(
[bla] =>
[bla:protected] =>
)
I tried to fix this bug and found three solutions:
1) when the new class does its inheritance checks it could 'm
