ISO/IEC TR 24731-2:2010
(Main)Information technology — Programming languages, their environments and system software interfaces — Extensions to the C library — Part 2: Dynamic Allocation Functions
Information technology — Programming languages, their environments and system software interfaces — Extensions to the C library — Part 2: Dynamic Allocation Functions
ISO/IEC TR 24731 provides alternative functions for the C library that promote safer, more secure programming. ISO/IEC TR 24731-1 provides simple replacement functions for the library functions of ISO/IEC 9899:1999 that provide bounds checking. Those functions can be used as simple replacements for the original library functions in legacy code. ISO/IEC TR 24731-2:2010 presents replacements for many of these functions that use dynamically allocated memory to ensure that buffer overflow does not occur.
Technologies de l'information — Langages de programmation, leurs environnements et leurs systèmes d'interface de logiciel — Extensions à la bibliothèque C — Partie 2: Fonctions d'attribution dynamiques
General Information
Standards Content (Sample)
TECHNICAL ISO/IEC
REPORT TR
24731-2
First edition
2010-12-01
Information technology — Programming
languages, their environments and
system software interfaces — Extensions
to the C library —
Part 2:
Dynamic Allocation Functions
Technologies de l'information — Langages de programmation, leurs
environnements et leurs systèmes d'interface de logiciel — Extensions
à la bibliothèque C —
Partie 2: Fonctions d'attribution dynamiques
Reference number
ISO/IEC TR 24731-2:2010(E)
©
ISO/IEC 2010
---------------------- Page: 1 ----------------------
ISO/IEC TR 24731-2:2010(E)
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.
COPYRIGHT PROTECTED DOCUMENT
© ISO/IEC 2010
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.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO/IEC 2010 – All rights reserved
---------------------- Page: 2 ----------------------
ISO/IEC TR 24731-2:2010(E)
Contents
Foreword . iv
Introduction . v
i
1.Scope . 1
2. Normative references . 1
3. Terms, definitions, and symbols . 1
4. Predefined macro names . 2
5.Library . 3
5.1 Introduction . 3
5.1.1 Standard headers . 3
5.1.2 Reserved identifiers . 3
5.1.3 Use of errno . 4
5.2 Input/output . 5
5.2.1Streams . 5
5.2.2 Operations on buffers . 5
5.2.3 Formatted input/output functions . 10
5.2.4 Character input/output functions . 12
5.3 String handling . 14
5.3.1 Copying functions . 14
5.4 Extended multibyte and wide character utilities . 15
5.4.1 Operations on buffers . 15
5.4.2 Formatted wide character input/output functions . 16
5.4.3 Wide character input/output functions . 17
Annex A (informative) Comparison Of Library Methods . 19
A.1Introduction . 19
Index . 23
©ISO/IEC 2010 - All rights reserved iii
---------------------- Page: 3 ----------------------
ISO/IEC TR 24731-2:2010(E)
Foreword
ISO (the International Organization for Standardization) and IEC (the
International Electrotechnical Commission) form the specialized system for
worldwide standardization. National bodies that are members of ISO or IEC
participate in the development of International Standards through technical
committees established by the respective organization to deal with particular
fields of technical activity. ISO and IEC technical committees collaborate in fields
of mutual interest. Other international organizations, governmental and non-
governmental, in liaison with ISO and IEC, also take part in the work. In the field
of information technology, ISO and IEC have established a joint technical
committee, ISO/IEC JTC 1.
International Standards are drafted in accordance with the rules given in the
ISO/IEC Directives, Part 2.
The main task of the joint technical committee is to prepare International
Standards. Draft International Standards adopted by the joint technical
committee are circulated to national bodies for voting. Publication as an
International Standard requires approval by at least 75% of the national bodies
casting a vote.
In exceptional circumstances a technical committee may propose the publication
of a Technical Report of one of the following types:
—type 1, when the required support cannot be obtained for the publication of
an International Standard, despite repeated efforts;
—type 2, when the subject is still under technical development or where for
any other reason there is the future but not immediate possibility of an
agreement on an International Standard;
—type 3, when a technical committee has collected data of a different kind
from that which is normally published as an International Standard ("state
of the art", for example).
Technical Reports of types 1 and 2 are subject to review within three years of
publication, to decide whether they can be transformed into International
Standards. Technical Reports of type 3 do not necessarily have to be reviewed
until the data they provide are considered to be no longer valid or useful.
Attention is drawn to the possibility that some of the elements of this document
may be the subject of patent rights. ISO and IEC shall not be held responsible for
identifying any or all such patent rights.
ISO/IEC TR 24731-2, which is a Technical Report of type 2, was prepared by
Joint Technical Committee ISO/IEC JTC 1, Information technology,Subcommittee
SC 22, Programming languages, their environments and system software interfaces.
iv © ISO/IEC 2010 - All rights reserved
---------------------- Page: 4 ----------------------
ISO/IEC TR 24731-2:2010(E)
ISO/IEC TR 24731 consists of the following parts, under the general title
Information technology—Programming languages, their environments and system
software interfaces—Extensions to the C library:
—Part 1: Bounds-checking interfaces
—Part 2: Dynamic Allocation Functions
©ISO/IEC 2010 - All rights reserved v
---------------------- Page: 5 ----------------------
ISO/IEC TR 24731-2:2010(E)
Introduction
Traditionally, the C library has contained many functions that trust the
programmer to provide output character arrays big enough to hold the result
being produced. Not only do these functions not check that the arrays are big
enough, they frequently lack the information needed to perform such checks.
While it is possible to write safe, robust, and error-free code using the existing
library, the library tends to promote programming styles that lead to mysterious
failures if a result is too big for the provided array.
Perhaps the most common programming style is to declare character arrays large
enough to handle most practical cases. However, if the program encounters
strings too large for it to process, data is written past the end of arrays
overwriting other variables in the program. The program never gets any
indication that a problem exists, and so never has a chance to recover or to fail
gracefully.
Worse, this style of programming has compromised the security of computers
and networks. Daemons are given carefully prepared data that overflows
buffers and tricks the daemons into granting access that should be denied.
If the programmer writes run time checks to verify lengths before calling library
functions, then those run time checks frequently duplicate work done inside the
library functions, which discover string lengths as a side effect of doing their job.
ISO/IEC TR 24731 provides alternative functions for the C library that promote
safer, more secure programming. ISO/IEC TR 24731-1 provides simple
replacement functions for the library functions of ISO/IEC 9899:1999 that
provide bounds checking. Those function can be used as simple replacements for
the original library functions in legacy code. This part of ISO/IEC TR 24731
presents replacements for many of these functions that use dynamically allocated
memory to ensure that buffer overflow does not occur. Since the use of such
functions requires adding additional calls to free the buffers later, these functions
are better suited to new developments than to retrofitting old code.
In general, the functions described in this part of ISO/IEC TR 24731 provide
much greater assurance that buffer overflow problems will not occur, since
buffers are always automatically sized to hold the data required. With the
bounds checking functions, if an invalid size was passed to one of the functions,
it could still suffer from buffer overflow problems, while appearing to have
addressed such issues. Applications that use dynamic memory allocation might,
however, suffer from denial of service attacks where data is presented until
memory is exhausted.
These functions are drawn from existing implementations that have widespread
usage. Many of these functions are included in ISO/IEC 9945:2003 (POSIX) and
as such are aligned with that International Standard.
vi © ISO/IEC 2010 - All rights reserved
---------------------- Page: 6 ----------------------
ISO/IEC TR 24731-2:2010(E)
Many of the interfaces in this part of ISO/IEC TR 24731 are derived from
interfaces specified in other ISO/IEC International Standards, and in particular
ISO/IEC 9945:2003 (including Technical Corrigendum 1), and
ISO/IEC 23360:2006.
Where an interface is described as being derived from either of these
International Standards, the functionality described on this reference page is
intended to be aligned with that International Standard. Any conflict between
the requirements described in this part of ISO/IEC TR 24731 and the referenced
International Standard is unintentional. This part of ISO/IEC TR 24731 defers to
the underlying International Standard.
©ISO/IEC 2010 - All rights reserved vii
---------------------- Page: 7 ----------------------
TECHNICAL REPORT ISO/IEC TR 24731-2:2010(E)
Information technology — Programming languages, their
environments and system software interfaces — Extensions to
the C library —
Part 2:
Dynamic Allocation Functions
1. Scope
ISO/IEC TR 24731 specifies a series of extensions of the programming language
C, specified by ISO/IEC 9899:1999. ISO/IEC 9899:1999 provides important
context and specification for this part of ISO/IEC TR 24731. Clause 4 should be
read as if it were merged into ISO/IEC 9899:1999, 6.10.8. Clause 5 should be read
as if it were merged into the parallel structure of named subclauses of
ISO/IEC 9899:1999, Clause 7.
2. Normativereferences
The following referenced documents are indispensable for the application of this
document. For dated references, only the edition cited applies. For undated
references, the latest edition of the referenced document (including any
amendments) applies.
ISO/IEC 9899:1999, Programming languages—C.
ISO/IEC 9899:1999/Cor-1:2001, Programming languages—C—Technical
Corrigendum 1.
ISO/IEC 9899:1999/Cor-2:2004, Programming languages—C—Technical
Corrigendum 2.
ISO/IEC 9899:1999/Cor-3:2007, Programming languages—C—Technical
Corrigendum 3.
ISO/IEC 23360:2006, Linux standard Base (LSB) core specification 3.1
3. Terms, definitions, and symbols
For the purposes of this document, the terms and definitions given in
ISO/IEC 9899:1999 apply. Other terms are defined where they appear in italic type.
NOTE: Terms explicitly defined in this part of ISO/IEC TR 24731 do not refer
implicitly to similar terms defined elsewhere.
©ISO/IEC 2010 - All rights reserved 1
---------------------- Page: 8 ----------------------
ISO/IEC TR 24731-2:2010(E)
4. Predefined macro names
The following macro name is conditionally defined by the implementation:
__STDC_ALLOC_LIB_ _ The integer constant 201004L,intended to indicate
1)
conformance to this technical report.
1) The intention is that this will remain an integer constant of type long int that is increased with
each revision of this technical report.
2© ISO/IEC 2010 - All rights reserved
---------------------- Page: 9 ----------------------
ISO/IEC TR 24731-2:2010(E)
5. Library
5.1 Introduction
5.1.1 Standardheaders
The functions, macros, and types defined in Clause 5 and its subclauses are not
defined by their respective headers if__STDC_WANT_LIB_EXT2_ _ is defined as
amacro which expands to the integer constant0 or is not defined as a macro at
the point in the source file where the appropriate header is included.
The functions, macros, and types defined in Clause 5 and its subclauses are
defined by their respective headers if__STDC_WANT_LIB_EXT2_ _ is defined as
amacro which expands to the integer constant 1 at the point in the source file
2)
where the appropriate header is included.
Within a preprocessing translation unit,__STDC_WANT_LIB_EXT2_ _ shall be
defined identically for all inclusions of any headers from Clause 5. If
__STDC_WANT_LIB_EXT2_ _ is defined differently for any such inclusion, the
implementation shall issue a diagnostic as if a preprocessor error directive was
used.
5.1.2 Reservedidentifiers
Each macro name in any of the following subclauses is reserved for use as
specified if it is defined by any of its associated headers when included; unless
explicitly stated otherwise (see ISO/IEC 9899:1999 Subclause 7.1.4).
All identifiers with external linkage in any of the following subclauses are
reserved for use as identifiers with external linkage if any of them are used by
the program. None of them are reserved if none of them are used.
Each identifier with file scope listed in any of the following subclauses is
reserved for use as a macro name and as an identifier with file scope in the same
name space if it is defined by any of its associated headers when included.
2) Future revisions of this technical report may define meanings for other values of
__STDC_WANT_LIB_EXT2_ _.
©ISO/IEC 2010 - All rights reserved 3
---------------------- Page: 10 ----------------------
ISO/IEC TR 24731-2:2010(E)
5.1.3 Use of errno
An implementation may set errno for the functions defined in this technical
report, but is not required to.
4© ISO/IEC 2010 - All rights reserved
---------------------- Page: 11 ----------------------
ISO/IEC TR 24731-2:2010(E)
5.2 Input/output
5.2.1 Streams
In addition to the requirements of ISO/IEC 9899:1999, clause 7.19.2, streams may
be associated with memory buffers.
Astream associated with a memory buffer has the same operations for text files
that a stream associated with an external file would have. In addition, the stream
orientation is determined in exactly the same fashion.
Input and output operations on a stream associated with a memory buffer by a
3)
call to fmemopen, open_memstream or open_wmemstream are constrained
by the implementation to take place within the bounds of the memory buffer. In
the case of a stream opened by open_memstream or open_wmemstream,the
memory area grows dynamically to accommodate write operations as necessary.
For output, data are moved from the buffer provided by setvbuf to the
memory stream during a flush or close operation. If there is insufficient memory
to grow the memory area, or the operation requires access outside of the
associated memory area, the associated operation fails.
5.2.2 Operations on buffers
5.2.2.1 Thefmemopen function
Synopsis
#define _ _STDC_WANT_LIB_EXT2_ _ 1
#include
FILE * fmemopen(void * restrict buf,
size_t size, const char * restrict mode);
Description
This interface is derived from POSIX. Any conflict between the requirements
described here and POSIX is unintentional. This technical report defers to POSIX.
The fmemopen function associates the buffer given by the buf and size
arguments with a stream. Thebuf argument is either a null pointer or points to a
buffer that is at leastsize bytes long.
Themode argument is a character string having one of the following values:
r Open text stream for reading.
w Open text stream for writing.
3) Theopen_wmemstream function is defined in.
©ISO/IEC 2010 - All rights reserved 5
---------------------- Page: 12 ----------------------
ISO/IEC TR 24731-2:2010(E)
a Append; open text stream for writing at the first null byte.
r+Open text stream for update (reading and writing).
w+Open text stream for update (reading and writing).
Truncate the buffer contents.
a+Append; open text stream for update (reading and
writing); the initial position is at the first null byte.
rb Open binary stream for reading.
wb Open binary stream for writing.
ab Append; open binary stream for writing at the first null
byte.
rb+or r+b Open binary stream for update (reading and writing).
wb+or w+b Open binary stream for update (reading and writing).
Truncate the buffer contents.
ab+or a+b Append; open binary stream for update (reading and
writing); the initial position is at the first null byte.
If a null pointer is specified as the buf argument, fmemopen allocates size
bytes of memory as if by a call to malloc.This buffer shall be automatically
freed when the stream is closed. Because this feature is only useful when the
stream is opened for updating (because there is no way to get a pointer to the
buffer) the fmemopen call may fail if the mode argument does not include a +
whenbuf is a null pointer.
The stream maintains a current position in the buffer. This position is initially set
to either the beginning of the buffer (for r and w modes) or to the first null byte in
the buffer (for a modes). If no null byte is found in append mode, the initial
position is set to one byte after the end of the buffer.
Ifbuf is a null pointer, the initial position shall always be set to the beginning of
the buffer.
The stream also maintains the size of the current buffer contents. For modes r
and r+ the size is set to the value given by thesize argument. For modes w and
w+ the initial size is zero and for modes a and a+ the initial size is either the
position of the first null byte in the buffer or the value of the size argument if no
null byte is found.
Aread operation on the stream cannot advance the current buffer position
beyond the current buffer size. Reaching the buffer size in a read operation
counts as "end of file". Null bytes in the buffer have no special meaning for reads.
The read operation starts at the current buffer position of the stream.
6© ISO/IEC 2010 - All rights reserved
---------------------- Page: 13 ----------------------
ISO/IEC TR 24731-2:2010(E)
Awrite operation starts either at the current position of the stream (if mode has
not specified a as the first character) or at the current size of the stream (if mode
had a as the first character). If the current position at the end of the write is larger
than the current buffer size, the current buffer size is set to the current position.
Awrite operation on the stream cannot advance the current buffer size beyond
the size given in the size argument.
When a stream open for writing is flushed or closed, a null byte is written at the
current position or at the end of the buffer, depending on the size of the contents.
If a stream open for update is flushed or closed and the last write has advanced
the current buffer size, a null byte is written at the end of the buffer if it fits.
An attempt to seek a memory buffer stream to a negative position or to a position
larger than the buffer size given in thesize argument shall fail.
Note that when writing to a text stream, line endings may occupy more than one
character in the buffer.
Returns
The fmemopen function returns a pointer to the object controlling the stream. If
the open operation fails
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.