packed records' address again

[Gale Paeper]

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 at empirenet.com