intialization of output formal parameters in modelica functions

[Willi Braun]

I guess we should set an implicit default value for formal output parameters, even if I haven't found that sentence in the spec. Of course, that's bad modelica code and we should try at least to warn the user, but I think the MSL is full of such stuff.
What do you think?

Example:

function f
  input Real x;
  output Real a;
  output Real b;
algorithm
  if x > 0.5 then
    a := sin(x);
  else
    b := cos(x);
  end if;
end f;

model A
 Real x,y,z;
equation
 der(x) = x+y+z;
 (y,z) = f(time);
end A;

BTW.: This is also the reason for our mysterious failing of simulation_libraries_msl32.Modelica.Electrical.Spice3.Examples.Nor.mos
with the clang compiler.

[Martin Sjölund]

No, the MSL isn't full of it. But it has a few such cases. And we do have code that tries to warn the user. The problem is that a function called in the rhs may fail (assertion/ModelicaError in external code) which means you will generate warnings even for valid code (this is usually the case in MSL). If you want, feel free to fix the code so it takes more of these things into account.

The specification is quite clear on the fact that you should not set a default for undefined formal output parameters. Instead tell me which function gives undefined result in Spice3 Nor and I will patch it and create a modelica.org bug report.

[Willi Braun]

Okay, could you point me to that clear sentence in the spec?
I've found only that only for local variables:

The local variables of a function are not automatically initialized to the implicit default values of the data type.

The following function Modelica_Electrical_Spice3_Internal_Mos_mosCalcNoBypassCode couses the behavoir above.

[Martin Sjölund]

Output format parameters are local variables within the function body itself. (You can use them as variables if you like, e.g. out := 1.0; protVar := out;)

As for this one, I believe my code doesn't look for unassigned parts of a record and considers assigning to any of them assigning to all of them.

[Martin Sjölund]

Created bug report ​#994

[Martin Sjölund]

I'm working on updating the existing code to take records into account. It seems feasible to do.

[Martin Sjölund]

A little over 100 tests changed output. Most are 3rd-party libraries (ThermoSysPro), possibly from copying code from Fluid (a few of those functions give warnings now). And of course... Spice3.

[Martin Sjölund]

Fixed (patched MSL) in r15249. I also started checking for unassigned record components (except parameters).