One of our tireless field testers reported a problem today relating to member initializers in a DEFSTRUCT that is then used with DIMX that is serious enough that I'm posting it here just to maximize the its visibility.

An example will help clarify. Consider:

The above is perfectly legal, and CUS.DISCOUNT will be initialized to 0.10, just as if a statement CUS.DISCOUNT = STD'DISCOUNT was executed automatically when the MAP1 CUS,ST_CUS statement is processed. (That's exactly what happens.)

But, if you try to create an array of ST_CUS structures, i.e.:

you'll get a compiler error. This is because the initialization statement generated by the MAP statement only works for simple scalar variables. The same restriction applies to regular multi-level arrays, i.e.:

(Basic has always had this restriction, and it simplY got inherited by DEFSTRUCT.)

The newly identified problem is that when you use DIMX to allocate an array of structures in which there is an initializer, not only did the compiler fail to generate an error, it instead generated code with a orphaned initializer token, which could have bad results at runtime.

For example:

As of 6.0.1255.9 (compil edit 521), and also 6.1.1315.2 (compil edit 606), the initializer will now simply be ignored when DIMX is used. This is better than generating garbage, but could still lead to application problems if you were counting on the initialization (although you already had that problem). The other option was to treat any initializer within a DEFSTRUCT as a compiler error, but I was afraid this would cause problems for people who are correctly using initializers with simple non-array structures.

Better would be to warn you about the potential problem, but we don't really have a solid framework for handling compiler warnings. (This is something that should be addressed in 6.1.) Even better still would be to support the initializers within arrays, but it turns out to be rather complex, and doesn't seem worth the benefit (relative to other features that could be implemented with the same time and effort).

So now for, consider yourself forewarned. (And update to 6.0.1255.9 (or 6.1.1315.2) and then recompile if you think you might have affected (infected?) code.

And if you have any ideas about the best way to handle compiler warnings, please start a new topic and share them here.

Could we get an EL5 6.1 build please.

Would the same problem occur if STD'DISCOUNT had been defined rather than mapped:

DEFINE STD'DISCOUNT = 0.10

Yes, it has to do with the way initialization occurs. i.e. the compiler adds the line CUS.DISCOUNT = STD'DISCOUNT just after the variable definition.

So for a DIMX array the would have to be
The problem really is that the initialization is currently done at compile time with no run-time component. There would have to be a run-time component for DIMX because we often don't know how many elements will be allocated for array until run-time.

Couldn't have said it better myself.

But I can always try... :rolleyes:

Actually, to be semantically precise, the assignment statement (generated by the compiler while processing the MAP statement) does actually execute at runtime, so in that sense there is a run-time component. The problem is that the compiler doesn't have any good way, at least now (absent a lot of work), to save the generated assignments for each defstruct field initializer and insert them, in a loop, after after any arrays of the structure are generated. (It would be particularly complex to do this during an auto-extend operation, since in the general case, the assignment could require further evaluation of runtime expressions.)

A better (and possibly future) way of dealing with this would be to switch to an object-oriented scheme, treating the structure as an object and calling a fully-functional (user defined) initializer routine for each new instance (including array elements) of the object.

If we run out of things to talk about in San Diego, we can add this to the list...

So as a rule, one is better off not initializing any elements of a structure in a DEFSTRUCT (even if it's legal to do so) nor an array in a MAP statement. All initialization of a structure's or array's elements should be explicitly done at run time. Is that correct?

Yes, I would say it's probably best to avoid the potential problem by avoiding map statement initialization within DEFSTRUCTs.

This begs another question, for those of us on the cutting edge should we be using 6.0 or 6.1? Are they basically the same now? I don't want to have to catch up a bunch of versions. I know this is the wrong place but you mentioned 6.1 above...

Please stay on 6.0!

6.1 does have a couple of additional features, but they are obscure and won't be of much interest to you. I didn't just put them into 6.0 because they involved touching a lot of code, and the idea of 6.0 is to keep it stable. Not that it has worked out that way, with a fairly continuous stream of minor fixes, refinements and even a few enhancements. But that's even more reason to stay on it, because maintaining 6.0 is the priority right now. (Patches get replicated to 6.1 periodically, but the focus is definitely 6.0.)

At some point, 6.0 really will become stable and 6.1 will become the focus, but that may not be until after the Conference (where we will hopefully set some new development targets and priorities).

is there an AIX Compiler (edit 520) or full Ashell update floating about?

Sorry, not yet. But I'll try to bring the AIX version up to date soon...

Thanks.

Ok, 6.0.1256.1 for AIX posted in the usual place.

Got it, Thanks.