IEEE P1003.2 Draft 11.2 - September 1991 Copyright (c) 1991 by the Institute of Electrical and Electronics Engineers, Inc. 345 East 47th Street New York, NY 10017, USA All rights reserved as an unpublished work. This is an unapproved and unpublished IEEE Standards Draft, subject to change. The publication, distribution, or copying of this draft, as well as all derivative works based on this draft, is expressly prohibited except as set forth below. Permission is hereby granted for IEEE Standards Committee participants to reproduce this document for purposes of IEEE standardization activities only, and subject to the restrictions contained herein. Permission is hereby also granted for member bodies and technical committees of ISO and IEC to reproduce this document for purposes of developing a national position, subject to the restrictions contained herein. Permission is hereby also granted to the preceding entities to make limited copies of this document in an electronic form only for the stated activities. The following restrictions apply to reproducing or transmitting the document in any form: 1) all copies or portions thereof must identify the document's IEEE project number and draft number, and must be accompanied by this entire notice in a prominent location; 2) no portion of this document may be redistributed in any modified or abridged form without the prior approval of the IEEE Standards Department. Other entities seeking permission to reproduce this document, or any portion thereof, for standardization or other activities, must contact the IEEE Standards Department for the appropriate license. Use of information contained in this unapproved draft is at your own risk. IEEE Standards Department Copyright and Permissions 445 Hoes Lane, P.O. Box 1331 Piscataway, NJ 08855-1331, USA +1 (908) 562-3800 +1 (908) 562-1571 [FAX] P1003.2/D11.2 INFORMATION TECHNOLOGY--POSIX The effect of defining the _POSIX_C_SOURCE macro to any other value is unspecified. If there are no feature test macros present in a program, only the set of symbols defined by the C Standard {7} shall be present. For each feature test macro present, only the symbols specified by that feature test macro plus those of the C Standard {7} shall be defined when the header is included. BEGIN_RATIONALE B.1.1.1 POSIX Symbols Rationale. (_T_h_i_s _s_u_b_c_l_a_u_s_e _i_s _n_o_t _a _p_a_r_t _o_f _P_1_0_0_3._2) When the application defines the _POSIX_C_SOURCE feature test macro with 1 value 2, it must be aware that all of the name space from POSIX.1 {8} and 1 POSIX.2 has been reserved. This does not imply that a POSIX.2 implementation must support POSIX.1 {8}, just that the application must not conflict with an implementation that does. The application can check _POSIX_VERSION and _POSIX2_C_VERSION at compile time to see which 1 standards are supported, if that is necessary. This is primarily an issue for the headers , , , and , since other POSIX.1 {8} names appear in other headers not mentioned in POSIX.2. It is expected that C bindings to future POSIX standards and revisions will define new values for _POSIX_C_SOURCE, with each new value reserving 1 the name space for that new standard or revision, plus all earlier POSIX standards. Using a single feature test macro for all standards rather than a separate macro for each standard furthers the goal of eventually combining all of the C bindings into one standard, which will be included in an international standard that refers to a language-independent ISO/IEC 9945-1 {8}. END_RATIONALE B.1.2 Headers and Function Prototypes Implementations shall declare function prototypes for all functions. Each function prototype shall appear in the header included in the synopsis of the function. Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 910 B C Language Bindings Option Part 2: SHELL AND UTILITIES P1003.2/D11.2 B.1.3 Error Numbers Some of the functions in this annex use the variable _e_r_r_n_o to report errors. Such usage is documented in Errors in each specification. The usage of _e_r_r_n_o and the meanings of the symbolic names shall be as defined in POSIX.1 {8} B.1.3. BEGIN_RATIONALE B.1.4 C Language Definitions Rationale. (_T_h_i_s _s_u_b_c_l_a_u_s_e _i_s _n_o_t _a _p_a_r_t _o_f _P_1_0_0_3._2) This clause clarifies the interface to the C Standard {7}. The description was taken from POSIX.1, with one important modification. 1 Since POSIX.1 {8} and the C Standard {7} were being developed and 1 approved at about the same time, POSIX.1 {8} allowed ``Common Usage C'' 1 implementations to give system vendors time to develop Standard C 1 interfaces. Since Standard C compilers are now commonly available, 1 POSIX.2 does not explicitly describe the binding to Common Usage C. However, such a binding would be straightforward, as long as the rules for Common Usage C in POSIX.1 are followed. END_RATIONALE B.2 C Numerical Limits The following subclauses list the names of macros that C language applications can use to obtain minimum and current values for limits defined in 2.13.1. BEGIN_RATIONALE B.2.0.1 C Numerical Limits Rationale. (_T_h_i_s _s_u_b_c_l_a_u_s_e _i_s _n_o_t _a _p_a_r_t _o_f _P_1_0_0_3._2) This subclause was added in Draft 9 to give C applications access to limits at compile time. Applications can use the values from the macros without resorting to _s_y_s_c_o_n_f(). The descriptions very closely follow the descriptions of macros and limits in POSIX.1 {8}. This definition of the limits is specific to the C language. Other language bindings might use different interfaces or names to provide equivalent information to the application. Note that there are no C bindings or interfaces that change based on the macros in Table B-5. These macro only advertise the availability of the Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. B.2 C Numerical Limits 911