Austin Group Defect Tracker

Aardvark Mark IV


Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0000526 [1003.1(2008)/Issue 7] System Interfaces Objection Clarification Requested 2011-12-12 10:26 2019-06-10 08:55
Reporter geoffclare View Status public  
Assigned To ajosey
Priority normal Resolution Accepted  
Status Closed  
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
Attached Files

- Relationships
related to 0000400Closedajosey 1003.1(2008)/Issue 7 realloc wording conflicts with C99 
related to 0000520Closedajosey 1003.1(2008)/Issue 7 posix_memalign should not modify memptr on failure 
related to 0000374Appliedajosey 1003.1(2008)/Issue 7 malloc(0) and realloc(p,0) must not change errno on success 
related to 0000688Closed 1003.1(2013)/Issue7+TC1 realloc(NULL, 0) vs. malloc(0) 

-  Notes
(0001129)
nick (manager)
2012-02-15 20:34

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."

- Issue History
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


Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker