J3/02-162

Date:        26 Mar 2002
To:          J3
From:        R. Maine
Subject:     Changes to list of unresolved issues

The following are changes made to the list of unresolved issues.
These changes are reflected in 02-011r1 and in the J3 notes of
02-007R1.

These changes add 10 new issues, resolve 18, and change 0.  This
makes a total of 366 issues, 355 of which have been resolved,
and 11 of which remain.

I. Resolved issues

  Paper 02-109r2 resolved issue 340.

  Paper 02-110r2 resolved issue 349.

  Paper 02-113r1 resolved issue 348.

  Paper 02-119 resolved issue 352.

  Paper 02-120r1 resolved issue 354.

  Paper 02-128r2 resolved issue 353.

  Paper 02-129r2 resolved issue 334 and 335.

  Paper 02-136r2 resolved issues 341, 342, 345, and 346.

  Paper 02-146r2 resolved issues 355 and 356.

  Paper 02-154r1 resolved issues 343 and 350.

  Paper 02-155r1 resolved issue 351.

  Paper 02-156 resolved issue 344.

II. Changed unresolved issues

  None.

III. New unresolved issues

  paper 02-136r2

    issue 357 - Unqualified interoperability

      The issue on this in the paper is numbered 357.

    issue 358 - ENTRY and BIND

      The issue on this in the paper is numbered 358.

  paper 02-149

    issue 359 - argument lists in 13.6

      While entering paper 02-149, I noticed that there were
      similar errors in 13.6, some dating back to f90.  We should
      either fix them also or (my preference) delete the argument
      lists entirely from 13.6.  That's not where anyone looks
      for argument lists.  besides, deleting the argument lists
      would make the column headers (which just say these are
      names) correct.

  paper 02-111r2

    issue 360 - semicolons still

      On reading the result, I'm still not convinced that these
      words unambiguously address the recurring question of
      whether it is legal to end a line with a semicolon.  In
      spite of the change to consistently use the term
      "termination", we still have the claim that the semicolon
      "allows" another statement to begin on the same line.  That
      "allows" is vague as to exactly what situations do and do
      not start a new statement.  It is possible to interpret
      this as meaning that a new statement does start (and then
      is an invalid empty statement).    Perhaps if we
      just plain say it instead of letting it be deduced, things
      would be simpler.

      The use of the terms "also" and "optional" are also
      confusing.  Does "also" mean "alternatively" here, or does
      it mean that the statement is simultaneously terminated by
      two different things (whatever that would mean).  I think
      it means "alternatively".  The "optional" is confusing in
      that the semicolon is certainly not optional if there are
      two statements on the same line.

  paper 02-111r2

    issue 361 - "this three" modules

      Item 12 of paper 02-138r2 added the above reference to
      ``this module'', along with one other simillar reference
      in this section and two in 14.7.  However, the referent for
      ``this'' is unclear.  Three intrinsic modules are defined
      in Section 14.  One of the references is even in a sentence
      that begins by specifying two of the three modules, making
      the referent particularly confusing.

      I'll suggest that at least in the above case, this could be
      fixed just by removing material.  It is in a clause
      introduced by ``examples are,'' which implies that the list
      is incomplete (and it's implication is correct).

    issue 362 - IEEE restrictions

      The papers's issue in it's item 34 is numbered as 362.

    issue 363 - Underflow and inexact

      Item 33 of paper 02-138r2 says to delete the ``unless the
      result is exact'' from the above note.  John Reid says this
      deletion is incorrect.  Resolution deferred to J3.

  paper 02-129r2

    issue 364 - Subclause 7.3

      Paper 02-129r2 emasculated this subclause (7.3), and
      reasonably so.  We should probably finish the job.  What
      remains is one short sentence of meat (the first one).  The
      second sentence is all but identical to one in 7.2 (on
      intrinsic operations).  The third also applies equally well
      to intrinsic and defined operations.  One sentence doesn't
      seem enough for a top-level subclause in a clause about 36
      pages long.  None of the other top-level subclauses here
      are down to distinguishing between intrinsic and derived
      operations.  I suggest we merge this material into 7.2.
      The two sentences that apply to all operations can be
      stated once in a way that applies to all.  The one sentence
      of meat can either remain a sentence or can be a
      one-sentence subclause one level lower (7.2.5, presumably).
      Minor editing to 7.2.0 would be needed.

  paper 02-132r1

    issue 365 - iostat and iomsg in dtio

      As mentioned in discussion of paper 02-132r1, there needs
      to be a note discussing the iostat and iomsg arguments.
      The note needs to mention that the values of these
      arguments are not necessarily passed through as is to the
      parent i/o statement.  If we don't mention this explicitly,
      a lot of people will assume that the value is passed
      through and that we just forgot to specify that.

  not associated with any paper

    issue 366 - C99 types

      I can't find the int_least*_t and int_fast*_t types in
      6.2.5 of the C99 standard, or anywhere else in it either...
      Oh, finally found them in 7.18, about 220 pages away from
      6.2.5.  That xref is pretty misleading.  Perhaps it used to
      be right in some C99 draft.  Is this the only wrong C xref?