The next item in the CPC changes list is a fix of the compiler.
It does not report an error when an actual IN parameter is passed to
a formal VAR receiver parameter in the call of a type-bound procedure, e.g.
r.ModifyR();
where r is an IN parameter and ModifyR is declared as
PROCEDURE (VAR r: R) ModifyR();
This means that although the formal receiver parameter is a VAR,
an IN parameter can be passed and thereby modified without any error message.
Since this behavior is actually used at several places in the BB distribution, a number of files
in addition to DevCPP needs to be adapted.
see: http://redmine.blackboxframework.org/issues/38
The changes are exactly as in CPC 1.7 rc5 plus the required changes in the docu of Meta,
which were missing.
The redmine replication and the build engine seem to be disabled.
Ivan, could you please check our Edis host?
- Josef
issue-#38 report passing receiver parameter IN to VAR
- Josef Templ
- Posts: 2047
- Joined: Tue Sep 17, 2013 6:50 am
Re: issue-#38 report passing receiver parameter IN to VAR
I agree that this "feature" is bad. But is it a bug, or just an ambiguity in the language report?
I wonder what the Queensland compiler does?
I wonder what the Queensland compiler does?
- Josef Templ
- Posts: 2047
- Joined: Tue Sep 17, 2013 6:50 am
Re: issue-#38 report passing receiver parameter IN to VAR
As far as I see the language report does not make a distinction between
compatibility rules for the receiver and other parameters.
It would also not give much sense to support both IN and VAR for the receiver
without making any difference between them in the compatibility checking.
- Josef
compatibility rules for the receiver and other parameters.
It would also not give much sense to support both IN and VAR for the receiver
without making any difference between them in the compatibility checking.
- Josef
- Josef Templ
- Posts: 2047
- Joined: Tue Sep 17, 2013 6:50 am
Re: issue-#38 report passing receiver parameter IN to VAR
the voting is over and the changes are merged.
- Josef
- Josef