(j3.2006) READ unit ambiguity
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 220.127.116.11).
> 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