(j3.2006) READ unit ambiguity

[Robert Corbett]

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 7.1.9.2).

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.