gSOAP: soap_new_T calls result in creating arrays

Hi Philippe,

While reviewing Fesapi’s code lately we noticed that the soap_new_T() functions are systematically called with 2nd parameter equal to ‘1’, like in:

resqml2__BinaryContactInterpretationPart* contact = soap_new_resqml2__BinaryContactInterpretationPart(org->soap, 1);

According to gSOAP’s documentation, ‘1’ means an array of one element:

T * soap_new_T(struct soap *soap, int n) allocates and default-initializes and array of type T , where n = -1 allocates a single non-array value.

Even though this does not seem to be causing any issue, do you know why ‘-1’, which is actually the default value for that parameter, is not used instead?

Note: As far as I can see the code that gSOAP itself creates does use the default, like in:

SOAP_FMAC3 std::vector<gmd__MD_USCOREIdentifier_USCOREPropertyType *> * SOAP_FMAC4 soap_in_std__vectorTemplateOfPointerTogmd__MD_USCOREIdentifier_USCOREPropertyType(struct soap *soap, const char *tag, std::vector<gmd__MD_USCOREIdentifier_USCOREPropertyType *> *a, const char type)
(void)type; /
appease -Wall -Werror */
short soap_flag;
for (soap_flag = 0;; soap_flag = 1)
if (tag && *tag != ‘-’)
{ if (soap_element_begin_in(soap, tag, 1, NULL))
if (!a && !(a = soap_new_std__vectorTemplateOfPointerTogmd__MD_USCOREIdentifier_USCOREPropertyType(soap)))

Hi Philippe,

Actually, we learn only recently what you very clearly explain. I don’t really know why we have put 1 as a parameter at the fesapi beginning : probably just a mistake on our side (or maybe a gsoap change which we have never taken into account).
We want to adopt the right way : use the default value for the soap_new_T parameter resulting in creating a single non-array value.
I think we actually started to switch to this new approach : see (open conversation l.502 for example) but it looks I did not pay attention enough to later reviews.

We have not done the change in all our source code mainly because it does not look necessary but we’ll have to. I have reported this issue on GitHub to take it into account

Thanks for your question!

Ok, it is under control then.

Thanks for the fast answer (and the hard work!).

Best regards,

For completeness of this post: