Define a null pointer-to-shared in terms of C99's "null pointer constant"

Issue #65 new
Former user created an issue

Originally reported on Google Code with ID 65

Version 1.2 of the UPC specification 6.4.3p1 states the following:

Constraints
1 A shared type qualifier shall not appear in a type cast where the
corresponding pointer component of the type of the expression being cast is not shared-qualified.[9]
An exception is made when the constant expression 0 is cast, the result is called the
null pointer-to-shared.[10]

Consider the following:

#define NULL ((void *) 0)
shared [4] int *p3 = (shared [4] int *)NULL;

Above, technically NULL is not a "constant expression 0".  Rather it is
a "null pointer constant".  Per 6.3.2.3p2 of the C99 specification:

An integer constant expression with the value 0, or such an expression cast to type
void *, is called a null pointer constant.55) If a null pointer constant is converted
to a pointer type, the resulting pointer, called a null pointer, is guaranteed to compare
unequal to a pointer to any object or function.

Footnote [55] states:
The macro NULL is defined in <stddef.h> (and other headers) as a null pointer constant;
see 7.17.

Based on the above, this issue proposes that the language above be amended to state:

"An exception is made when a null pointer constant is cast ...".

There may be other locations in the UPC specification where similar adjustments need
to be made.

Reported by gary.funck on 2012-07-17 19:24:32

Comments (11)

  1. Former user Account Deleted

    ``` I endorse this proposed clarification/correction to 6.4.3p1 ```

    Reported by `phhargrove@lbl.gov` on 2012-07-17 19:26:57

  2. Former user Account Deleted

    ``` Set default Consensus to "Low". ```

    Reported by `gary.funck` on 2012-08-19 23:26:19 - Labels added: Consensus-Low

  3. Former user Account Deleted

    ``` Change Status to New: Requires review. ```

    Reported by `gary.funck` on 2012-08-19 23:37:41 - Status changed: `New`

  4. Former user Account Deleted

    Reported by `gary.funck` on 2012-08-19 23:46:24 - Labels added: Consensus-Medium - Labels removed: Consensus-Low

  5. Former user Account Deleted

    ``` This issue seems straightforward and likely to have high consensus. Official proposal mailed 9/21/2012

    --- upc-language.tex (revision 119) +++ upc-language.tex (working copy) @@ -327,8 +327,9 @@ \npf A shared type qualifier shall not appear in a type cast where the corresponding pointer component of the type of the expression being cast is not shared-qualified.\footnote{i.e., pointers-to-local - cannot be cast to pointers-to-shared.} An exception is made when the constant - expression 0 is cast, the result is called the {\em null + cannot be cast to pointers-to-shared.} An exception is made when + \xreplaced[id=DB]{65}{a null pointer constant}{the constant expression 0} + is cast, the result is called the {\em null pointer-to-shared}.\footnote{[ISO/IEC00 Sec. 6.3.2.3/6.5.16.1] imply that an implicit cast is allowed for zero and that all null pointers-to-shared compare equal.}

    ```

    Reported by `danbonachea` on 2012-09-21 21:51:45 - Status changed: `PendingApproval` - Labels added: Consensus-High - Labels removed: Consensus-Medium

  6. Former user Account Deleted

    ``` I agree that this is a "no brainer" change to the spec language to use the proper terminology for what we have all understood from the beginning.

    Dan's comment actually collided with mine intended to say the same thing (though w/o the diff). ```

    Reported by `phhargrove@lbl.gov` on 2012-09-21 22:00:42

  7. Former user Account Deleted

    ``` I have a question though. We are nowhere saying that the NULL pointer-to-shared should actually have all-zero values in its implementation (whatever the flavor of implementation of a UPC pointer-to-shared is).

    We had a UPC test case at some point where a NULL pointer-to-shared was copied (with upc_memcpy) into a local data structure and then the code went on making assumptions about the "zeroness" of the copied data.

    Are we ready to say something about this? that a NULL pointer-to-shared is all zeroes in its implementation?

    -- George

    ```

    Reported by `ga10502` on 2012-09-26 19:31:53

  8. Former user Account Deleted

    ``` George asks:

    Are we ready to say something about this? that a NULL pointer-to-shared is all zeroes

    in its implementation?

    I'd say NO, we are not prepared to say that. The C99 spec is careful NOT to demand that the in-memory representation of NULL is zero, but does require that the representation will compare equal to zero. This puts the burden on the compiler, when generating code to compare pointers, to "do the right thing" when the representation of NULL is not all-zero-bits.

    I am too lazy to go check, but I think BUPC will (for one of the choice of representation we support) treat any pointer with zero in the addrfield of the representation as a shared NULL, regardless of the thread and phase.

    There is an entire c-faq section related to NULL in C99 at http://c-faq.com/null/ ```

    Reported by `phhargrove@lbl.gov` on 2012-09-26 19:45:35

  9. Former user Account Deleted

    ``` I agree with Paul, we should not require zeroes for implementation, and a test that depends on it is incorrect. The language doesn't even require that upc_addrfield return zero for a NULL pointer-to-shared, let alone that some portion of the implementation of the pointer actually contain zero. The common shortcut of clearing a structure (that may contain pointers) by bzero or memset rather than zeroing each field I think is not valid C practice. ```

    Reported by `brian.wibecan` on 2012-09-26 22:36:53

  10. Former user Account Deleted
    these issues have all reached the end of their 4-week comment period 
    and were accepted into the working draft at the 10/31 telecon.
    Committed SVN r181
    

    Reported by danbonachea on 2012-10-31 20:49:32 - Status changed: Ratified

  11. Log in to comment