Was running pspell through g++ and found that a couple of error conditions segments in pspell.c
are using the wrong cleanup methods. delete_pspell_manager() should be delete_pspell_can_have_error()
-Phil.
--- pspell.c 16 Jul 2008 18:35:41 -0000 1.61
+++ pspell.c 11 Aug 2008 17:39:03 -0000
@@ -374,7 +374,7 @@
if(pspell_error_number(ret) != 0){
php_error_docref(NULL TSRMLS_CC, E_WARNING, "PSPELL couldn't open the dictionary. reason: %s",
pspell_error_message(ret));
-
delete_pspell_manager(ret);
-
delete_pspell_can_have_error(ret); RETURN_FALSE; }
@@ -492,7 +492,7 @@
if(pspell_error_number(ret) != 0){
php_error_docref(NULL TSRMLS_CC, E_WARNING, "PSPELL couldn't open the dictionary. reason: %s",
pspell_error_message(ret));
-
delete_pspell_manager(ret);
-
delete_pspell_can_have_error(ret); RETURN_FALSE; }
@@ -526,7 +526,7 @@
if(pspell_error_number(ret) != 0){
php_error_docref(NULL TSRMLS_CC, E_WARNING, "PSPELL couldn't open the dictionary. reason: %s",
pspell_error_message(ret));
-
delete_pspell_manager(ret);
-
delete_pspell_can_have_error(ret); RETURN_FALSE; }
Was running pspell through g++ and found that a couple of error conditions segments in pspell.c
are using the wrong cleanup methods. delete_pspell_manager() should be delete_pspell_can_have_error()
We'd certainly need some more details to get this patch committed, not just "this should that".
--
Wbr,
Antony Dovgal
Antony Dovgal wrote:
Was running pspell through g++ and found that a couple of error
conditions segments in pspell.c
are using the wrong cleanup methods. delete_pspell_manager() should
be delete_pspell_can_have_error()We'd certainly need some more details to get this patch committed, not
just "this should that".
Well I thought the patch was fairly simple but if you'd like a full explination..
g++ -I. -I/usr/home/phil/vps2/user/contrib/php5/ext/pspell -DPHP_ATOM_INC -I/usr/home/phil/vps2/user/contrib/php5/ext/pspell/include -I/usr/home/phil/vps2/user/contrib/php5/ext/pspell/main -I/usr/home/phil/vps2/user/contrib/php5/ext/pspell -I/usr/local/php5/include/php -I/usr/local/php5/include/php/main -I/usr/local/php5/include/php/TSRM -I/usr/local/php5/include/php/Zend -I/usr/local/php5/include/php/ext -I/usr/local/php5/include/php/ext/date/lib -I/usr/local/include/pspell -DHAVE_CONFIG_H -g -O2 -c /usr/home/phil/vps2/user/contrib/php5/ext/pspell/pspell.c -fPIC -DPIC -o .libs/pspell.o
/usr/home/phil/vps2/user/contrib/php5/ext/pspell/pspell.c: In function void zif_pspell_new(int, zval*, zval**, zval*, int)': /usr/home/phil/vps2/user/contrib/php5/ext/pspell/pspell.c:254: error: cannot convertAspellCanHaveError*' to AspellSpeller*' for argument1' to void delete_aspell_speller(AspellSpeller*)' /usr/home/phil/vps2/user/contrib/php5/ext/pspell/pspell.c: In functionvoid zif_pspell_new_personal(int, zval*, zval**, zval*, int)':
/usr/home/phil/vps2/user/contrib/php5/ext/pspell/pspell.c:377: error: cannot convert AspellCanHaveError*' toAspellSpeller*' for argument 1' tovoid delete_aspell_speller(AspellSpeller*)'
/usr/home/phil/vps2/user/contrib/php5/ext/pspell/pspell.c: In function void zif_pspell_new_config(int, zval*, zval**, zval*, int)': /usr/home/phil/vps2/user/contrib/php5/ext/pspell/pspell.c:411: error: cannot convertAspellCanHaveError*' to AspellSpeller*' for argument1' to `void delete_aspell_speller(AspellSpeller*)'
as you can see we are using the wrong destructor in these three cases. Looking at the code you find:
PspellCanHaveError *ret;
if(pspell_error_number(ret) != 0){
php_error_docref(NULL TSRMLS_CC, E_WARNING, "PSPELL couldn't open the dictionary. reason: %s ", pspell_error_message(ret));
delete_pspell_manager(ret);
RETURN_FALSE;
}
do a little grep'ing and we find the prototype is..
grep delete_pspell_manager /usr/local/include/pspell/pspell.h
#define delete_pspell_manager delete_aspell_speller
grep delete_aspell_speller /usr/local/include/aspell.h
void delete_aspell_speller(struct AspellSpeller * ths);
I do a little detective work and find...
grep delete_aspell_can_have_error /usr/local/include/aspell.h
void delete_aspell_can_have_error(struct AspellCanHaveError * ths);
transpose this to the pspell wrapper..
grep delete_aspell_can_have_error /usr/local/include/pspell/pspell.h
#define delete_pspell_can_have_error delete_aspell_can_have_error
Thus the diff -u I sent in.. which resolves the above compiler failure with g++.
-Phil.
Thus the diff -u I sent in.. which resolves the above compiler failure with g++.
Committed, thanks!
Btw, how and why did you manage to get g++ compiling plain C code?
--
Wbr,
Antony Dovgal
Antony Dovgal wrote:
Thus the diff -u I sent in.. which resolves the above compiler failure
with g++.Committed, thanks!
Btw, how and why did you manage to get g++ compiling plain C code?
umm.. how?
cd ext/pspell
/usr/local/php5/bin/phpize
env CC=g++ CFLAGS=-fuse-cxa-atexit ./configure --with-php-config=/usr/local/php5/bin/php-config
make
C++ is a superset of C thus any C code can be complied as C++ as long as it doesn't use any
C++ reserved words. Plus, C++ has much stronger type checking and it is worth a run through
at least occasionally to double checking that code is sane.
as to why? well that is more complicated.. I'm mainly tilting at windmills..
but I've been trying to find a simpler resolution to my php setup crashing with
a SEGFAULT when Zend Optimizer is installed and pspell is a shared extension.
I'm starting to suspect it is something misbehaving in the Optimizer, but I need
to organize my research before I present any theories publicly.
-Phil.
Antony Dovgal wrote:
Thus the diff -u I sent in.. which resolves the above compiler failure
with g++.Committed, thanks!
Btw, how and why did you manage to get g++ compiling plain C code?
umm.. how?
cd ext/pspell
/usr/local/php5/bin/phpize
env CC=g++ CFLAGS=-fuse-cxa-atexit
./configure --with-php-config=/usr/local/php5/bin/php-config
makeC++ is a superset of C thus any C code can be complied as C++ as long as
it doesn't use any
C++ reserved words.
That is not true at all, although it's a common misconception.
Just try the following in C and in C++:
printf("sizeof('x') == %d\n", (int)sizeof('x'));
(hint: they will give you different results). And there are many more
differences..
Nuno
Nuno Lopes wrote:
Antony Dovgal wrote:
Thus the diff -u I sent in.. which resolves the above compiler
failure with g++.Committed, thanks!
Btw, how and why did you manage to get g++ compiling plain C code?
umm.. how?
cd ext/pspell
/usr/local/php5/bin/phpize
env CC=g++ CFLAGS=-fuse-cxa-atexit ./configure
--with-php-config=/usr/local/php5/bin/php-config
makeC++ is a superset of C thus any C code can be complied as C++ as long
as it doesn't use any
C++ reserved words.That is not true at all, although it's a common misconception.
Just try the following in C and in C++:
printf("sizeof('x') == %d\n", (int)sizeof('x'));(hint: they will give you different results). And there are many more
differences..Nuno
Yes.. there are some differences, but if your very careful with your typing..
C can be compiled with a C++ compiler.
printf("sizeof('x') == %d\n", (int) sizeof((char)'x'));
gives the same output of 1, with gcc and g++.
I really don't want to be a troll. I still espouse that compiling a C program
with a C++ compiler even if you never actually run it that way is a definite
advantage to catch type checking problems.
-Phil.
C++ is a superset of C thus any C code can be complied as C++ as long as
it doesn't use any
C++ reserved words.That is not true at all, although it's a common misconception.
Just try the following in C and in C++:
printf("sizeof('x') == %d\n", (int)sizeof('x'));(hint: they will give you different results). And there are many more
differences..Nuno
Yes.. there are some differences, but if your very careful with your
typing..
C can be compiled with a C++ compiler.printf("sizeof('x') == %d\n", (int) sizeof((char)'x'));
gives the same output of 1, with gcc and g++.
I really don't want to be a troll. I still espouse that compiling a C
program
with a C++ compiler even if you never actually run it that way is a
definite
advantage to catch type checking problems.
Yes sure. I was just warning that compiling foreign C code with a C++
compiler is dangerous because you don't know if it's using some C specific
feature or not.
Anyway this is already too much offtopic :)
Nuno