View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000526 | 1003.1(2008)/Issue 7 | System Interfaces | public | 2011-12-12 10:26 | 2019-06-10 08:55 |
| Reporter | geoffclare | Assigned To | ajosey | ||
| Priority | normal | Severity | Objection | Type | Clarification Requested |
| Status | Closed | Resolution | Accepted | ||
| Name | Geoff Clare | ||||
| Organization | The Open Group | ||||
| User Reference | |||||
| Section | calloc() | ||||
| Page Number | 627 | ||||
| Line Number | 21395, 21399 | ||||
| Interp Status | --- | ||||
| Final Accepted Text | |||||
| Summary | 0000526: Adopt C99 wording for zero size calloc(), malloc() et al. | ||||
| Description | While correcting the application of 0000400 in the TC1 draft it was noticed that the wording related to the zero size case for calloc(), malloc() and realloc() is different in C99, which says: If the size of the space requested is zero, the behavior is implementation-defined: either a null pointer is returned, or the behavior is as if the size were some nonzero value, except that the returned pointer shall not be used to access an object. The C99 wording is better because it avoids explicit mention of passing the returned pointer to free(), thus ensuring there can be no doubt about whether the pointer can also be deallocated by realloc(). In fact, 0000400 already changes the realloc() DESCRIPTION wording to match C99 but does not remove the now-redundant mention of free() in the RETURN VALUE section. The proposed changes also make the errno handling for calloc() and malloc() more consistent with the realloc() change in 0000400, although using "may" because they don't have the same need for errno to indicate that the space was not freed. In addition they tidy up an editorial problem with duplicate statements in the 0000400 text about the returned pointer being used to access an object. (The statement is made once as "shall not be used" as in C99, and once as "the application shall ensure ..."; the changes turn the first one into a statement about undefined behaviour, since the second is the appropriate POSIX wording.) For consistency, similar changes should be made for posix_memalign(). | ||||
| Desired Action | At page 627 line 21395 section calloc() page 1268 line 41713 section malloc() change: If the size of the space requested is 0, the behavior is implementation-defined: the value returned shall be either a null pointer or a unique pointer. to: If the size of the space requested is 0, the behavior is implementation-defined: either a null pointer shall be returned, or the behavior shall be as if the size were some nonzero value, except that the behavior is undefined if the returned pointer is used to access an object. At page 627 line 21399 section calloc() page 1268 line 41718 section malloc() change: either a null pointer or a unique pointer that can be successfully passed to free() shall be returned. to: either: * a null pointer shall be returned <CX>and errno may be set to an implementation-defined value</CX>, or * a pointer to the allocated space shall be returned. The application shall ensure that the pointer is not used to access an object. For realloc() ... After applying the page 1754 line 56030 change from 0000400, change: except that the returned pointer shall not be used to access an object. to: except that the behavior is undefined if the returned pointer is used to access an object. After applying the line 56047-8 change from 0000400, change: [a] unique pointer that can be successfully passed to free() shall be returned to: a pointer to the allocated space shall be returned At page 1418 line 46423 section posix_memalign() change: If the size of the space requested is 0, the behavior is implementation-defined; the value returned in memptr shall be either a null pointer or a unique pointer. to: If the size of the space requested is 0, the behavior is implementation-defined: either a null pointer shall be returned in memptr, or the behavior shall be as if the size were some nonzero value, except that the behavior is undefined if the the value returned in memptr is used to access an object. At page 1418 line 46429 section posix_memalign() after: an error number shall be returned to indicate the error. add the following new text: If size is 0, either: * posix_memalign() shall not attempt to allocate any space, in which case either an implementation-defined error number shall be returned, or zero shall be returned with a null pointer returned in memptr * posix_memalign() shall attempt to allocate some space and if the allocation succeeds, zero shall be returned and a pointer to the allocated space shall be returned in memptr. The application shall ensure that the pointer is not used to access an object. (Note that 0000520 proposes a change to the text that precedes this. I have worded this change in a way that ensures the two changes can be made independently.) | ||||
| Tags | c99, tc2-2008 | ||||
| related to | 0000400 | Closed | ajosey | 1003.1(2008)/Issue 7 | realloc wording conflicts with C99 |
| related to | 0000520 | Closed | ajosey | 1003.1(2008)/Issue 7 | posix_memalign should not modify memptr on failure |
| related to | 0000374 | Closed | ajosey | 1003.1(2008)/Issue 7 | malloc(0) and realloc(p,0) must not change errno on success |
| related to | 0000688 | Closed | 1003.1(2013)/Issue7+TC1 | realloc(NULL, 0) vs. malloc(0) |
|
|
At the Feb 2012 WG14 meeting, the committee looked again at the realloc(p,0) issue, and are proposing the following changes to C to clarify things and to permit applications that had erroneously assumed that realloc(p,0) was the same as free(p) (i.e. the case where realloc(p,0) returns NULL and frees the p):
In subsection 7.22.3 paragraph 1, change
"If the size of the space requested is zero,
the behavior is implementation-defined:
either a null pointer is returned, ..."
to
"If the size of the space requested is zero,
the behavior is implementation-defined:
either a null pointer is returned to indicate an error, ..."
In subsection 7.22.3.5 (The {realloc} function),
change the final sentence of paragraph 3 from
"If memory for the new object cannot be allocated,
the old object is not deallocated and its value is unchanged."
to
"If {size} is non-zero and memory for the new object is not allocated,
the old object is not deallocated.
If {size} is zero and memory for the new object is not allocated,
it is implementation-defined whether the old object is deallocated.
If the old object is not deallocated, its value shall be unchanged."
In subsection 7.22.3.5 (The {realloc} function),
change paragraph 4 from
"The realloc function returns a pointer to the new object
(which may have the same value as a pointer to the old object),
or a null pointer if the new object could not be allocated."
to
"The realloc function returns a pointer to the new object
(which may have the same value as a pointer to the old object),
or a null pointer if the new object has not been allocated."
Add to subsection 7.31.12 a new paragraph (paragraph 2):
"Invoking realloc with a size argument equal to zero
is an obsolescent feature."
|
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2011-12-12 10:26 | geoffclare | New Issue | |
| 2011-12-12 10:26 | geoffclare | Status | New => Under Review |
| 2011-12-12 10:26 | geoffclare | Assigned To | => ajosey |
| 2011-12-12 10:26 | geoffclare | Name | => Geoff Clare |
| 2011-12-12 10:26 | geoffclare | Organization | => The Open Group |
| 2011-12-12 10:26 | geoffclare | Section | => calloc() |
| 2011-12-12 10:26 | geoffclare | Page Number | => 627 |
| 2011-12-12 10:26 | geoffclare | Line Number | => 21395, 21399 |
| 2011-12-12 10:26 | geoffclare | Interp Status | => --- |
| 2011-12-12 10:27 | geoffclare | Relationship added | related to 0000400 |
| 2011-12-12 10:28 | geoffclare | Relationship added | related to 0000520 |
| 2011-12-15 16:04 | nick | Tag Attached: c99 | |
| 2012-02-15 20:34 | nick | Note Added: 0001129 | |
| 2012-02-16 17:15 | nick | Relationship added | related to 0000374 |
| 2012-02-16 17:24 | nick | Status | Under Review => Resolved |
| 2012-02-16 17:24 | nick | Resolution | Open => Accepted |
| 2012-02-16 17:24 | nick | Description Updated | |
| 2012-02-16 17:24 | nick | Desired Action Updated | |
| 2012-02-16 17:24 | nick | Tag Attached: tc2-2008 | |
| 2013-05-09 15:57 | eblake | Relationship added | child of 0000688 |
| 2013-05-09 16:23 | eblake | Relationship deleted | child of 0000688 |
| 2013-05-09 16:23 | eblake | Relationship added | related to 0000688 |
| 2019-06-10 08:55 | agadmin | Status | Resolved => Closed |
