Hi Maxime,
The Ada run-time behaviour is really not that strange. It is a general paradigm in Ada that
discriminants always hold a legal value.
At the place where your C wrapper code is called, I have declared an Ada object which is explicitly initialized by the run-time system in order to maintain the invariant that all discriminants are well-formed.
The best solution hence is for you to disregard the waste of CPU, and initialize the output parameter ‘currentvalue’ with the contents of this Ada object before
you call my user code.
The file parameterpool_vm_if.c
would then have to read something like this:
void parameterpool_getParameter (void *pmy_id, size_t size_my_id, void *pmy_currentvalue, size_t *psize_my_currentvalue)
{
/* Decoded input variable(s): developer can use them */
static asn1SccParameter_ID IN_id;
/* Output variable(s): developer has to fill them */
static asn1SccParameter_Value OUT_currentvalue;
#ifdef __unix__
memset(&IN_id, 0, sizeof(asn1SccParameter_ID));
memset(&OUT_currentvalue, 0, sizeof(asn1SccParameter_Value));
#endif
/* Decode each input parameter */
if (0 != Decode_NATIVE_Parameter_ID (&IN_id, pmy_id, size_my_id)) {
printf("\nError Decoding Parameter_ID\n");
return;
}
/* Initialize each output parameter */
if (0 != Decode_NATIVE_Parameter_Value (&OUT_currentvalue, pmy_currentvalue, sizeof(asn1SccParameter_Value))) {
printf("\nError Decoding Parameter_Value\n");
return;
}
/* Call to User-defined function */
parameterpool_PI_getParameter (&IN_id, &OUT_currentvalue);
/* Encode each output parameter */
*psize_my_currentvalue = Encode_NATIVE_Parameter_Value (pmy_currentvalue, sizeof (asn1SccParameter_Value), &OUT_currentvalue);
}
Disabling of Ada checks is not a viable solution. These checks are one of the reasons for using Ada in the first place.
Regards,
Gert
P.P.S. Why do you initialize the IN_id variable with zeros — memset(&IN_id, 0, sizeof(asn1SccParameter_ID)); — if you are concerned about wasting CPU?
Gert Caspersen
Senior Engineer, Project Manager
Space Projects (DK)
Terma A/S
From:
Maxime Perrotin [mailto:Maxime.Perrotin@xxxxxxx]
Sent: 31 May 2012 17:32
To: taste-users@xxxxxxxxxxxxxxxxxxx; Gert Caspersen
Subject: Re: [taste-users] TASTE Wrapper Code Leading to Constraint Error
This one is very tricky, because the problem is actually due to a strange behaviour of the Ada runtime.
The code TASTE generates is correct:
procedure getParameter (id : access asn1sccParameter_ID; currentvalue : access asn1sccParameter_Value) is
begin
The second parameter is an output parameter, passed by reference (called from a C function which gives a pointer
to a valid variable).
Because it is an output parameter, we do not initialize it with a valid value BEFORE calling this function - it would
make no sense: setting a value that in any case will be overwritten would be a waste of CPU.
However, for some reasons, when in your user code you assign a value to this output parameter:
currentvalue.all := thePool(id.all);
Ada FIRST checks if currentvalue had a valid value, before trying to assign the new one. (!)
I have to say that I do not understand this. We have tried different options, like using an explicit OUT parameter
instead of "access" in the function parameter but it does not help.
So because the value is not initialized with a CHOICE discriminent that is valid, the check fails and Ada raises
an exception.
The only way we found around this is to explicitly disable the Ada checks at the begining of the function:
procedure getParameter (....)
pragma suppress(all_checks); <<--- Add this to your .adb code
We will automate this in the code skeleton generator, unless we find a better solution. Maybe you have an idea?
In the meantime, let me know if this solves the issue...
On Wed, 30 May 2012 16:07:16 +0200, Gert Caspersen <gec@xxxxxxxxx> wrote:
Hi Thanassis & Maxime,
I have now encountered a new problem with the generated TASTE code. Please see the enclosed extract from our problem database.
Any suggestions are highly appreciated.
Regards,
Gert
Gert Caspersen
Senior Engineer, Project Manager
Space Projects (DK)
Space
Terma A/S
Vasekær 12
2730 Herlev
Denmark
T +45 8743 6000
T +45 4594 9653 (direct)
F +45 8743 6001
E gec@xxxxxxxxx
W www.terma.com
Attention:
This e-mail (and attachment(s), if any) - intended for the addressee(s) only - may contain confidential, copyright, or legally privileged information
or material, and no one else is authorized to read, print, store, copy, forward, or otherwise use or disclose any part of its contents or attachment(s) in any form. If you have received this e-mail in error, please notify me by telephone or return e-mail,
and delete this e-mail and attachment(s). Thank you.
ESA - European Space Agency
PROBA V - PROBA 3 Software engineer
System, Software and Technology Department
NL-2200 AG Noordiwjk, The Netherlands
+31 (0)71 565 4923 | Fax +31 (0)71 565 5420
This message and any attachments are intended for the use of the addressee or addressees only. The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its content is not permitted. If you received this message in error, please notify the sender and delete it from your system. Emails can be altered and their integrity cannot be guaranteed by the sender.
Please consider the environment before printing this email.