(j3.2006) READ unit ambiguity

Robert Corbett robert.corbett
Fri Mar 2 14:29:09 EST 2012

On 03/02/12 11:13, Van Snyder wrote:
> On Fri, 2012-03-02 at 05:26 -0800, Bill Long wrote:
>> On 3/2/12 1:05 AM, Van Snyder wrote:
>>> Malcolm Cohen wrote:
>>>>> In a new post, Ian Harvey
>>>> Who is this guy? I hope you've invited him to join the committee!
>>>>> points out that Note 3.7 is
>>>>> no longer true. We can now have
>>>>> 10 .op. p = x
>>>>> where 10 can be a label or a left operand.
>>>> Now this one is very easily fixed - just delete free-form source and
>>>> the problem goes away.
>>> I obviously wasn't thinking of this case, but I did suggest, sometime
>>> prior to 1986, that both statement labels and construct labels ought to
>>> be followed by a colon in free form.
>> A bit too late for that.  However, we could (somewhat artificially)
>> disallow a statement number on a statement that looked like this.
>> Considering that statement numbers rarely show up in newer codes, I
>> would not expect much problem with backward compatibility.
> The standard doesn't establish an unambiguous interpretation for this
> statement, so it's not standard conforming.  It can be made conforming:
> (10 .op. p) = x

I I think that violates constraint C602.  I think that a
parenthesized expression is not a reference to a function.
A parenthesized expression certainly does not have a data
pointer result (see paragraph 3 of Clause

Bob Corbett
> or
> 10 (.op. p) = x
> Alternatively, we could write an ugly constraint on assignment to
> require the parentheses if the .op. is accessible in both unary and
> binary forms, and the unary form has a first argument of integer type.
> Ugh.  Or always.  Equally ughly.

More information about the J3 mailing list