Bring Conformance section into agreement with the C99 specification

[GoogleCodeExporter]

Using the "ISO/IEC 9899:TC3 Committee Draft — Septermber 7, 2007 WG14/N1256" 
version of the C99 specification as the point of reference, the beginning of 
the Conformance section reads as follows.

4. Conformance

1 In this International Standard, ‘‘shall’’ is to be interpreted as a 
requirement on an implementation or on a program; conversely, ‘‘shall 
not’’ is to be interpreted as a prohibition.

2 If a ‘‘shall’’ or ‘‘shall not’’ requirement that appears 
outside of a constraint is violated, the behavior is undefined. Undefined 
behavior is otherwise indicated in this International Standard by the words 
‘‘undefined behavior’’ or by the omission of any explicit definition of 
behavior. There is no difference in emphasis among these three; they all 
describe ‘‘behavior that is undefined’’.

The 1.2 version of the UPC Specification reads as follows.

4 Conformance

1 In this document, “shall” is to be interpreted as a requirement on a UPC
implementation; conversely, “shall not” is to be interpreted as a 
prohibition.

2 If a “shall” or “shall not” requirement is violated, the behavior is 
undefined. Undefined behavior is indicated by “undefined behavior” or by 
the omission of any explicit definition of behavior from the UPC specification.

As shown, the C99 specification makes the distinction that "shall" and "shall 
not" within a *constraint* will either describe a requirement or prohibition 
that is mandated by the specification.  Outside of a constraint, violation of 
the phrases "shall" or "shall not" is interpreted as undefined behavior.  This 
appears to be an important distinction.

Proposal: Bring the UPC specification statement of conformance into agreement 
with that used in the C99 specification.

In addition, the UPC specification's use of "shall", "shall not", and
"undefined behavior" should be reviewed to insure that they are in agreement 
with their intended use, per the C99 specification.

Original issue reported on code.google.com by gary.funck on 29 Jun 2012 at 11:50

[GoogleCodeExporter]

I also notice another significant difference in the two passages Gary quoted:

C99: "a requirement on an implementation or on a program"

UPC: "a requirement on a UPC implementation"

So I would request that this aspect of the UPC spec conformance language also 
be brought into alignment w/ C99.
Perhaps that was Gary's intent, but he was only clear about wanting the 
distinction made with regards to "shall" and "shall now" inside vs outside of a 
constraint.

Original comment by phhargr...@lbl.gov on 29 Jun 2012 at 11:59

[GoogleCodeExporter]

Paul, thanks for the clarification; that was my intent.

Original comment by gary.funck on 30 Jun 2012 at 12:15

[GoogleCodeExporter]

I fully endorse the (clarified) proposal to align Section 4 of the UPC 
specification with the corresponding C99 text.

Original comment by phhargr...@lbl.gov on 30 Jun 2012 at 12:41

[GoogleCodeExporter]

Original comment by gary.funck on 3 Jul 2012 at 3:10

• Added labels: Type-Clarification
• Removed labels: Type-Defect

[GoogleCodeExporter]

The reason C99 distinguishes between "shall" requirements inside and outside 
constraints is given in 5.1.1.3:

"A conforming implementation shall produce at least one diagnostic message 
(identified in
an implementation-defined manner) if a preprocessing translation unit or 
translation unit
contains a violation of any syntax rule or constraint, even if the behavior is 
also explicitly
specified as undefined or implementation-defined. Diagnostic messages need not 
be
produced in other circumstances"

In other words, "shall/shall not" constraint violations must issue a 
diagnostic. Violations of "shall/shall not" outside constraints just lead to 
undefined behavior.

The simplest solution may be to completely remove section 4 (Compliance), since 
it adds nothing to the C99 version, just replicates it (incorrectly). If we 
went this route then we should arrange for further section numbers to remain 
unchanged (and just have no section 4).

If people think this C99 section is important enough to replicate without 
change, then we should just do exactly that, replicate it word-for-word.

Original comment by danbonachea on 13 Aug 2012 at 4:10

[GoogleCodeExporter]

"If people think this C99 section is important enough to replicate
without change, then we should just do exactly that, replicate it
word-for-word."

I think that including the C99 section word-for-word improves the usability of 
the UPC language specification as a mostly stand-alone document, but would also 
have no problem with removing section 4 entirely (and preserving the current 
section numbers).

Original comment by gary.funck on 13 Aug 2012 at 5:54

[GoogleCodeExporter]

Set default Consensus to "Low".

Original comment by gary.funck on 19 Aug 2012 at 11:26

• Added labels: Consensus-Low

[GoogleCodeExporter]

Original comment by gary.funck on 19 Aug 2012 at 11:45

• Added labels: Consensus-High
• Removed labels: Consensus-Low

[GoogleCodeExporter]

I'm taking ownership of this one.

The C99 license:
"All rights reserved. Unless otherwise specified, no part of this publication 
may be reproduced or utilized in any form or by any means, electronic or 
mechanical, including photocopying and microfilm, without permission in writing 
from either ISO at the address below or ISO's member body in the country of the 
requester"

I don't think it falls within the letter or the spirit of the law to copy an 
entire chapter of C99 into our document without permission, no matter what it 
may contribute to our document.

So I'm proceeding to remove the body of section 4 and replace it with a 
reference to C99.

Original comment by danbonachea on 17 Sep 2012 at 5:51

[GoogleCodeExporter]

Official Change Proposal mailed to the list 9/17/2012

Description:
------------------
UPC 1.2's conformance section (chapter 4) differs in minor ways from C99 for no 
good reason. 
There is nothing UPC specific that needs to be said in this section, so we're 
proposing to replace it with a simple reference to the C document. Even this is 
slightly
redundant due to Section 1, but it preserves the section numbering which seems 
like a Good Thing.

Proposed Change:
-------------------------
--- upc-terms-and-defs.tex      (revision 119)
+++ upc-terms-and-defs.tex      (working copy)
@@ -116,14 +116,10 @@

 \section{Conformance}

-\npf In this document, ``shall'' is to be interpreted as a
-     requirement on a UPC implementation; conversely, ``shall not'' is to
-     be interpreted as a prohibition.
+\xchangenote[id=DB]{58}{TWO PARAGRAPHS THAT DUPLICATE C99 REMOVED}

-\np  If a ``shall'' or ``shall not'' requirement 
-     is violated, the behavior is undefined. Undefined behavior is
-     indicated by ``undefined behavior'' or by the omission of any
-     explicit definition of behavior from the UPC specification.
+\npf  All terminology and requirements defined in [ISO/IEC00 Sec. 4] also apply
+      to this document and UPC implementations.

 \pagebreak
 \section{Environment}

Original comment by danbonachea on 17 Sep 2012 at 6:04

• Changed state: PendingApproval

[GoogleCodeExporter]

This PendingApproval issue was ratified at the 10/19/2012 telecon, and merged 
into the working draft in SVN 175.

Original comment by danbonachea on 22 Oct 2012 at 6:43

• Changed state: Ratified