Re: Lowercase or camelcase function names?

Hi, On Mon, 07 Nov 2011 23:14:29 +0100 Johannes Schlüter <johannes@schlueters.de> wrote: [...] > > Fixed. No use of both of them anymore. > > I meant to say that "zval is the exact same thing as a pval was" (as a > pval was a typename'd zval, historically pval was from PHP 3 times) > zval can still be used (while zend_parse_paramters often makes it > unnecessary). I did not mean to say "zval is the same as pval and should > be dropped". I did understand that. I have anyway read a lot of the zval datatype in the past hours... interesting. I am learnig new stuff... ;) [...] > small comment: It is a convention to do a simple "return;" and therefore > return NULL if parameter parsing fails, not RETURN_FALSE. See note in > http://php.net/functions.internal Okay, thanks! Done and comitted... I think I found an example with "RETURN_FALSE" on the web. [...] > For a more complete check and more information on a Linux, BSD or Mac > system you can use valgrind. > $ USE_ZEND_ALLOC=0 valgrind --leak-check=full --show-reachable==yes /path/to/php script.php > or > $ /path/to/php run.tests.php -m > (if you have phpt tests) > > See Zend/README.ZEND_MM for a bit more on that. I am reading... I will not get sleep tonight... :/ [...] > > Will check that. Just "phpize && ./configure && make" fails... > > What kind of error do you get? hanez@phantom pcsc-for-php % make /bin/sh /home/hanez/projects/pcsc-for-php/libtool --mode=compile cc -I. -I/home/hanez/projects/pcsc-for-php -DPHP_ATOM_INC -I/home/hanez/projects/pcsc-for-php/include -I/home/hanez/projects/pcsc-for-php/main -I/home/hanez/projects/pcsc-for-php -I/usr/lib/php5.3/include/php -I/usr/lib/php5.3/include/php/main -I/usr/lib/php5.3/include/php/TSRM -I/usr/lib/php5.3/include/php/Zend -I/usr/lib/php5.3/include/php/ext -I/usr/lib/php5.3/include/php/ext/date/lib -I/usr/include/PCSC/ -DHAVE_CONFIG_H -g -O0 -c /home/hanez/projects/pcsc-for-php/pcsc.c -o pcsc.lo /home/hanez/projects/pcsc-for-php/libtool: line 481: CDPATH: command not found libtool: Version mismatch error. This is libtool 2.4, but the libtool: definition of this LT_INIT comes from an older release. libtool: You should recreate aclocal.m4 with macros from libtool 2.4 libtool: and run autoconf again. make: *** [pcsc.lo] Error 63 hanez@phantom pcsc-for-php % [...] > These two declarations are needed for a static build. If I need other > stuff in a header (usually only needed when having multiple .c files) I > try to keep the php_$extname.h one as short as the one shown above and > use a $extname_internal.h one for the other things. But that's just my > way. Not necessarily "the best". Okay. I really understand. I think I will follow your suggestions... I am working on this right now. > One thing I did not realize yesterday is that you're using the type > "LONG". C only defines a type "long". Is LONG defined in pcsc? Will it > be compatible to C's "long"? (C's long can be a bit "annoying" - > on > 32bit machines it is usually 32 bit. On 64bit Unix/Linux machines it > usually is 64bits, on 64bit Windows it's 32bit) Yes, it is defined in pcsc. I found this in a file called "wintypes.h"... :/ typedef int32_t LONG; I think to remember that this is part of the SCard API (PC/SC) definition. > > Should I do an account request in such a early state of the extension? > > I really would like to provide it ASAP but I don't know if you like > > 0.1.0 versions at pecl.php.net. A good thing would be the use of PHP's > > version control to keep changes at a central place... > > I think that's fine. You might give others one or two days for a chance > to object, though. Of course, then I have time to fix my bugs... ;) [...] > In PECL we aren't as strict as in PHP Core (where we aren't as strict as > we could be, either ...) but the closer it is to the general style the > simpler it becomes to get help ... from my perspective the key should be > to at least be consistent, right now you're mixing tabs and space, but I > assume you know. Yep. Johannes