On 02/06/13 21:20, Leyne, Sean wrote:
>
>>> Sean, currently code, calling UDF, looks this way
>>>
>>> template <typename T>
>>> T CALL_UDF(Jrd::Attachment* att, int (*entrypoint)(), UDF_ARG* args) {
>>> Jrd::Attachment::Checkout attCout(att, FB_FUNCTION);
>>> return ((T (*)(UDF_ARG, UDF_ARG, UDF_ARG, UDF_ARG, UDF_ARG,
>>> UDF_ARG, UDF_ARG, UDF_ARG, UDF_ARG, UDF_ARG))(entrypoint))
>>> (args[0], args[1], args[2], args[3], args[4], args[5],
>>> args[6], args[7], args[8], args[9]); }
>>>
>>> Certainly, it's possible to add args[10], args[11], etc. but this does
>>> not look like good solution.
>>> May be in a private build for you?
>>>
>> The current solution is already ugly,
Take into an account that it came from dark ages...
>> so I don't think adding some (not too
>> many) more would be bad.
> Would an increase to 15 params be a reasonable step?
Not sure for reasonable, but definitely possible.
>
>> A nice (but complex) solution would involve dynamic code generation
>> (possibly using a library).
> I agree, that would be ideal.
Adriano, I'm far not sure that it's worth much care about old UDF calls.
Added by you way of calling user programs superseeds it in all aspects.
Could it be available now the problem would be not raised at all.
------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
