Waldek Hebisch wrote:
Gale Paeper wrote:
[snip]
aSmallrecArray[1].arr := c; end.
I got these totally bogus errors when trying to compile:
CharArrayTest.pas: In main program: CharArrayTest.pas:28: error: using unpacked character arrays as strings
<snip> > The errors are totally bogus because there are abolutely no strings in > the program and there is nothing requiring string semantics in the
Agreed. The following patch should fix the problem:
Waldek, thanks for the timely response. While it doesn't fix the problems Francesco is having, I do appreciate that when compiler problems are discovered they are investigated and the problems get fixed commensurate with the time available and the problems' difficulty.
[snip]
smallrec = RECORD arr : char_arr; END;
[snip]
r.many_rec[1].arr := c; {compiler error but ISO7185/10206 legal} end.
And I got the same error you've been wrestling with:
PackedCharArrayTest.pas: In main program: PackedCharArrayTest.pas:31: error: cannot take address of packed record field `many_rec'
Again this is a bogus error. The assignment statememt "r.many_rec[1].arr := c;" is fully compliant with all requirements of ISO 7185/10206. The type of "r.many_rec[1].arr" is fixed-string-type with a capacity of 30 and "c" is fixed-string-type with capacity and length both 30 so per ISO 7185/10206 paragraph 6.4.6 f) and ISO 10206 paragraph 6.9.2.2 (6.8.2.2 for ISO 7185) the assignment statement is fully compliant with ISO requirements.
Agreed.
Okay. That is really the core of the problems Francesco is having. Although the complier doesn't have to statisfy any guarentees about economies of storage or efficiency of accesses, the compiler does have to handle assignment statements involving packed data structures as legal assignments.
I take it then that the problem has at least been put on the bug list to be investigated and fixed as time and circumstances permit addressing the problem?
I will note that ISO 7185/10206 puts one extra restriction and ONLY one extra restriction on the usage of a variable of packed type (including string types which are or contain packaged array types). From ISO 10206, paragraph 6.7.3.3:
"An actual variable parameter shall not denote a component of a variable where that variable possesses a type that is designated packed. An actual variable parameter shall not denote a component of a string-type."
However, that requirement doesn't even apply to "r.many_rec[1].arr" since the "arr" field is NOT a packed type compontent. Per ISO 10206. paragraph 6.4.3.1:
"The designation of a structured-type as packed shall affect the representation in data-storage of that structured-type only; i.e., if a component is itself structured, the component's representation in data-storage shall be packed only if the type of the component is designated packed."
In other words, even though the largerec type is designated "packed", the "arr" field isn't a packed field because the smallrec type has NOT been designated "packed".
Hmm, I do not understand what you are trying to argue here. "arr" field is not used as variable parameter, so 6.7.3.3 does not apply.
I was trying to agrue that there is only one case where the compiler should be issuing "cannot take address of packed record field" errors. That case being an actual packed component of a data structure being used as the actual parameter to a formal variable parameter. Since the code in question is neither an actual argument for a variable formal parameter or a packed component access, the compiler has no grounds for issuing a "cannot take address of packed record field" error.
(Regardless of the packed-ness of any data structure it is embedded in, there are no packed constraints on accessing the "arr" field since the smallrec record type was not declared packed. Accessing the individual char type elements of the "arr" field would have packed constraints since the char_arr was declared packed; however, the code in question isn't accessing the individual elements of the "arr" field so this isn't an issue.)
... The compiler message is about "many_rec", which is a packed record field (but the compiler does not see that the reference is legal).
That's the problem. The packed-ness of "many_rec" has no involvement in determining the legality of access to the "arr" component nor does it have any involvement in determining whether any of the nested components have packed type charateristics and whether or not the nested components accesses are subject to packed component usage constraints. The packed-ness of "many_rec" is completely out of the picture when it comes to legal accesses to the "arr" component so there is something really wrong with the compiler's handling of packed when it uses the packed charateristic of "many_rec" in determining the legality of accesses to the nested "arr" component.
Gale Paeper gpaeper@empirenet.com