Re: Fwd: [PATCH] added: openssl_csr_subject()

Wez Furlong wrote: >Two or three comments: > >- You leak the dynamically allocated buffer returned by X509_NAME_oneline() >- X509_NAME_oneline() man page says that its use is discouraged in >favour of smarter functions. Is there a possibility that someone will >need that functionality? >- if you can solve/answer both of the above, please post a link to the patch > > Now uses X509_NAME_print_ex(), using the XN_FLAGS_RFC2253 option. The only other flags for X509_NAME_print_ex() control the output string. I was going to add options for the php function to select them, but I don't see the use as the RFC2253 output is easily parsable and the other options don't do much (reverse order, or spaces instead of commas as delimiters). I also changed the prototype to be more like with the other openssl functions (returning bool): bool openssl_csr_subject(mixed csr, string &out) Now, I don't do very much C coding, and I'm pretty new to the zend API.. One thing I couldn't figure out was why (in php) openssl_csr_subject() won't put anything into $out if it's passed an undefined variable (where as openssl_csr_export, which is very similar, works). For example (let's pretend $csr is a string containing a PEM-encoded CSR): function test($csr) { openssl_csr_subject($csr, $out); var_dump($out); } will show "NULL", whereas: function test($csr) { openssl_csr_subject($csr, &$out); var_dump($out); } and function test($csr) { $out = NULL; openssl_csr_subject($csr, $out); var_dump($out); } both work fine, showing string (90) { "emailAddress=blah@php.net,OU=php...." } It looks to me like it has something to do with $out not being set (though, with $out = NULL isset($out) still returns false), but I'm still not sure why passing $out by reference at call-time would work in that case.