Did the problem arise for an exported procedure called by another module? I created RFE 117030 to address that problem.
Briefly described the problem is that the compiler does not enforce a prototype for exported procedures. That can lead to a situation where the procedure interface does not match the prototype (stored in a /copy member) and where a caller, that relies on the prototype, passes the wrong parameters to the procedure.
It is really nice that we no longer have to include the prototype for private procedures. But for exported procedures (Keyword: "export") the compiler MUST enforce the presence of a prototype.
Just my 2 cents.
Von: RPG400-L [mailto:rpg400-l-bounces@xxxxxxxxxxxx] Im Auftrag von Doug Englander
Gesendet: Mittwoch, 22. August 2018 19:37
Betreff: Prototype definition enforcement
Does anyone know if there is a way to have the compiler enforce [DCL-PR] prototype definitions against its associated DCL-PI definition? Earlier versions of RPG [i.e. maybe before V7R1] the compiler would give a message when the DCL-PR specs for a subprocedure in a module did not agree with the corresponding DCL-PI specs. Now that the compiler rules have been relaxed, it is now easier to have the DCL-PI and corresponding DCL-PR specs to become out of sync. For example, I have a DCL-PI in a module that does not accept parameters and just returns a value. I have changed the DCL-PR specs that are in a copybook, and they are pulled in, but they have defined parameter values being passed in. The compiler does not give any message about this. Does anyone know if there is a way to get the compiler to enforce the definitions like it used to do?