Hello
I'm wondering if there is a recommended way to validate a multi-type parameter
in an internal function. If a parameter is expected to be "long or string" or
to be "integer or null", a simple call to zend_parse_parameters() won't
validate it.
I read some extensions' code, and it seems that the preferred method is to call
zend_parse_parameters(_ex) several times until one validation succeeds or all
fail. I really don't like this solution. Maybe the performance penalty of
parsing twice the arguments is negligible, but I don't even like the idea of
this code. Isn't there a better solution? Or did I miss a good reason for this?
I wanted to use zend_parse_arg() to validate a single parameter if the
first call to zend_parse_parameters_ex() wasn't successful. But this function
is never used outside of "Zend/zend_API.c". Is it meant for public use? Are
there any drawbacks in calling it?
Regards
François Gannaz
Hi!
I wanted to use
zend_parse_arg()to validate a single parameter if the
first call tozend_parse_parameters_ex()wasn't successful. But this function
is never used outside of "Zend/zend_API.c". Is it meant for public use? Are
there any drawbacks in calling it?
No, it's currently not meant for public use - it's an internal function
that is not available to outside modules (thus declared 'static').
It may make sense to refactor this code and make it more accessible to
functions that want to parse individual parameter, but currently it is
not suited for that.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi
Hi!
I wanted to use
zend_parse_arg()to validate a single parameter if the
first call tozend_parse_parameters_ex()wasn't successful. But this
function is never used outside of "Zend/zend_API.c". Is it meant for public
use? Are there any drawbacks in calling it?No, it's currently not meant for public use - it's an internal function
that is not available to outside modules (thus declared 'static').
It may make sense to refactor this code and make it more accessible to
functions that want to parse individual parameter, but currently it is
not suited for that.
Thanks. As I'm new to php-src, it takes some time to understand this kind of
(undocumented?) conventions. I know it's a tedious task, but I'd really enjoy a
few comments for the Zend API functions.
I would rather do it differently - I'd allow to run parse on a single
parameter, i.e. have initial parse with 'z' and then depending on some code
have something like:zend_parse_single_arg(my_arg, "l", &l)
So you could do your own checks and then still benefit from the clean API
provided by parameter parser.
This is something you wrote on github, but I took the liberty to insert it here
as it is related. I thought zend_parse_arg() could be a substitute of your
zend_parse_single_arg(). It cannot be. So, is it worth adding this function
to the API? My own answer is yes, of course, but it does count much.
--
François Gannaz
No, it's currently not meant for public use - it's an internal
function
that is not available to outside modules (thus declared 'static').
It may make sense to refactor this code and make it more accessible
to
functions that want to parse individual parameter, but currently it
is
not suited for that.Thanks. As I'm new to php-src, it takes some time to understand this
kind of (undocumented?) conventions. I know it's a tedious task, but
I'd really enjoy a few comments for the Zend API functions.
Well, in this case the convention is quite simple:
* If it's static (like the mentioned case) you can't use it in
from a different file (or rather: compile unit) ... that's in
the C standard (-> internal linking)
* If it is ZEND_API/PHPAPI/... it can be used everywhere (while
TSRM should not use anything external, zend should use nothing
besides TSRM, for inter-extension dependencies one should be
careful)
* No-modifier-stuff can be used in the same library (same
extension), depending on compiler flags, compiler version, ...
this might (not) be enforced (by default we enforce it on
Windows and with "modern" gcc (4.1, I think), while you probably
won't see an effect with large static builds, which produce a
single, big, php binary only)
johannes
Hi!
Thanks. As I'm new to php-src, it takes some time to understand this kind of
(undocumented?) conventions. I know it's a tedious task, but I'd really enjoy a
few comments for the Zend API functions.
As Johannes mentioned, function marked "static" is a standard C feature
saying "this function is internal, do not try to use it from outside".
API functions are marked ZEND_API or PHP_API, you are not supposed to
use any functions not marked so in your extension unless they also
belong to the extension.
This is something you wrote on github, but I took the liberty to insert it here
as it is related. I thoughtzend_parse_arg()could be a substitute of your
zend_parse_single_arg(). It cannot be. So, is it worth adding this function
to the API? My own answer is yes, of course, but it does count much.
No, existing functions do not allow doing that, since they are written
as internal ones and thus rely on certain way of doing things. We'd need
to do some wrapper or refactoring there.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227