The Synergex development team recently enhanced the Synergy/DE compiler to generate warnings for suspicious code that can result in runtime errors or bad data. In most cases, these warnings were added in response to customer cases. The updated compiler will be available in a hotfix to 10.3.3c and an SDI developer build after 10.3.3c-2222. Several customers who are already using this compiler have had 1000+ warnings due to these changes. They were delighted that these new warnings allowed them to find coding errors at compile time rather than relying on their own runtime tests to catch them—or worse, having users catch obscure errors at runtime.

Synergex recommends that you fix all warnings to keep your code bases clean. Here are some of the new warnings. If these warnings are not addressed, they can cause variable corruption bugs at runtime.

%DBL-W-LITTRUNC, Literal truncated for destination
A literal has been stored into a variable, and it doesn’t fit without truncation. The literal should be updated to fit the destination or the destination should be increased in size.

%DBL-W-LITSIGN, Literal sign change
A number has been stored into an integer variable, but it only fits if treated as unsigned, e.g., 129 in an i1 field.

%DBL-W-PASSUR[2], Passing numeric type to decimal/integer type without conversion for parameter # in routine routine could give unexpected results
Synergy KnowledgeBase article 100002319 specifically addresses best-practice techniques to remove the coding error, and in many cases, a single routine parameter change fixes hundreds of warnings.

%DBL-W-REFTYPMSMCH, Parameter # must match type exactly because it is passed by reference, OUT, INOUT, or unspecified 
A subroutine or function has an object type parameter not marked as IN, and the passed argument is a different object type in the hierarchy. Because the called routine may do a NEW on the argument (in the absence of an IN qualifier), the argument must match exactly. In most cases, explicitly state IN on the called routine parameter.

%DBL-W-USEWARN, Using ^D on integer
As ^D is just a cast, the resulting d descriptor will have unexpected data. Most likely you meant to say %IMPLIED, not ^D.

%DBL-W-USEWARN, Using ^I on decimal
As ^I is just a cast, the resulting i descriptor will have unexpected data. Most likely you meant to say %INTEGER, not ^I.

%DBL-W-DIMMISMCH, Parameter dimension mismatch: parameter
An array variable argument without explicit dimension information was passed to an undimensioned parameter. The compiler implicitly added [1]. In most cases, you probably intended to type the parameter [*] to indicate passing the whole array, not the first element. If the first element was intended, add [1] to the call site.

%DBL-W-INVARG, Invalid argument:  #. Mark routine as varargs
You have used an argument access routine such as ^ARGPRECISION(4), and there are fewer than the specified number of declared arguments (in this case, less than four). Add “,varargs” to the routine declaration to fix this. If your routines are strongly prototyped, failure to add “,varargs” will result in a “Too many arguments” error if more arguments are passed than declared.

%DBL-W-ADDED[2], Conversion added from n to non_n for parameter parameter in routine routine name
We added an implicit conversion of your argument to guarantee the data. To remove this warning, use an explicit conversion.

While these are currently warnings to help you migrate code, we will change some of them to errors in a future release, as they represent a significant potential for runtime errors. Please let us know if you have suggestions for other warnings or errors we can add to the compiler to help you develop more robust code.

For more information, refer to Synergy KnowledgeBase article 100002319, “Implied vs. explicit parameters: Best practices for passing arguments.”