[PHP-DEV] Validate complex types

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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Hi!

> 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?

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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Hi

On 2012-03-23, Stas Malyshev <[email protected]> wrote:
> Hi!
>
> > 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?
>
> 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On Sat, 2012-03-24 at 11:57 +0100, François Gannaz wrote:
> > 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



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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 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.

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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php