From gwyn@ARL.MIL Mon Jul 8 07:58:11 1996 Received: from smokey.arl.mil (smokey.arl.mil [128.63.155.114]) by dkuug.dk (8.6.12/8.6.12) with SMTP id HAA12641; Mon, 8 Jul 1996 07:58:08 +0200 Date: Mon, 8 Jul 96 1:55:07 EDT From: Doug Gwyn (ASHPC/MCSB) To: Keld J|rn Simonsen cc: sc22wg15@dkuug.dk, sc22wg14@dkuug.dk Subject: Re: (SC22WG14.2683) WG14 N586: POSIX Alignment Message-ID: <9607080155.aa05095@SMOKEY.ARL.MIL> Here is my feedback on some of the I18N/POSIX-2 alignment proposals: > 7.3.1 Character testing functions I assume the intent is to single out "horizontal format effectors" as opposed to "format effectors". How well does this work with languages such as Chinese and Hebrew? > 7.3.2 Character case mapping functions Locale dependence is okay for these. > 7.4 Localization I think the POSIX-2 reference belongs in the Rationale, not the C language specification proper. > 7.4.1 Locale control If we reserve {yes,no}expr members of struct lconv, we have an obligation to specify something about them. I frankly don't believe that this is the right approach to parsing user input for "yes/no" responses to questions. > 7.4.1.1 setlocale() Again, the reference to POSIX locale registry belongs in the Rationale, not in the C language specification. Otherwise, we seem to be implying some degree of POSIX conformance is required for C conformance, > 7.4.2 Numeric formatting POSIX-2 is simply mistaken in overriding our specification of CHAR_MAX and specifying -1 instead. char is not necessarily capable of representing a value -1. This is fundamental to C and one wonders what got into the POSIX people. A defect report should be filed against POSIX-2 to request that this logical error in their specification be corrected. Note that a change to unsigned_char would reconcile the two specs, at the cost of backward compatibility for implementations having signed "char". > 7.4.2.1 p_sign_posn and n_sign_posn No problem here. > 7.4.2.1 int_curr_symbol different from currency_symbol No objection, if the I18N community thinks it is needed. > 7.12.3.5 strftime No problem, if implementors agree that it is not an undue burden. However, I think the references to ISO 8601 should be changed to self-contained specifications. YYYY-MM-DD presumably means 1996-07-08 for 8th of July, 1996 A.D.? > POSIX-1 section 8 (12 pages) should be considered for technical > corrigenda, or for inclusion in amendment/revision of the C standard. Only sections 8.1.1 and 8.1.2 should be considered for C9x. The rest of section 8 is too OS-specific, and the POSIX C binding is exactly the right place for it.