From crs@crs.cl.msu.edu Thu Apr 27 09:04:46 1995 Received: from crs.cl.msu.edu by dkuug.dk with SMTP id AA22576 (5.65c8/IDA-1.4.4j for ); Thu, 27 Apr 1995 19:04:42 +0200 Received: by crs.cl.msu.edu (5.65/MSU-2.08A) id AA06604; Thu, 27 Apr 1995 13:04:46 -0400 Date: Thu, 27 Apr 1995 13:04:46 -0400 From: Charles Severance Message-Id: <9504271704.AA06604@crs.cl.msu.edu> To: SC22WG15@dkuug.dk Subject: Some comments on the UK National Profile X-Charset: ASCII X-Char-Esc: 29 Note - This document is a response to the proposed UK National Profile. The review request was in WG15USTAG E-Mail 790. I do not have the original reference WG15 Mail message. Don's E-Mail address is dwc@eng.sun.com This should not be considered an official US position, just an informal response to a previous E-Mail. Charles Severance (crs@msu.edu) Secretary, US TAG to SC22/WG15 SC22/WG15 US TAG N517 April 26, 1995 Memorandum to US TAG to WG15 from Donald W. Cragun, Chair P1003.2 I have briefly reviewed the Draft United Kingdom(English) National Profile for POSIX Version 1.2, dated June 27, 1994. I do not feel qualified to comment on whether this profile would be beneficial for the UK, but have raised a few issues that would seem to cause technical problems for procurements and/or application writers using this profile: P13, L501: By requiring {MB_LEN_MAX} to be set to -1 (1-2), you make it impossible for any implementation to ever conform to the profile. Systems that support EUC, need to have {MB_LEN_MAX} set to 4 or 5. It would seem to be better to just require the implementation to support a value that conforms to the ISO C standard requirements. P13, L495-510: Specifying these values precludes having a 16 bit char to support UniCode (or ISO 10646) as a base character set having a 64 bit architecture have a 64 bit long data type. It would seem to be better to just require the implementation to support values for these limits as required by ISO C and POSIX. P13, L499-500: By specifying these required values for {CHAR_MIN} and {CHAR_MAX} you preclude implementations with type char being unsigned. It isn't obvious to this reviewer that requiring this will be beneficial in the long run. (Portable applications should be written to the ISO C standard requirements; they should specify signed char or unsigned char types, rather than an unadorned char when it matters.) P13, L514-516: By requiring that {POSIX_CHOWN_RESTRICTED}, and {POSIX_NO_TRUNC} be defined in with the value 1, you preclude the possibility of mounting file systems on a conforming implementation from a server that doesn't conform. Since mounting of these non-conforming file systems is done at the discretion of the system administrator, rather than by the system implementor, if you require this, you remove the ability for the implementation to access data from many non-POSIX compliant systems. You may want to find a different way of requiring support for these features. P28, L1277-1292: By specifying the , , and collating elements between and , you specify that the regular expression range expression [0-9] includes these characters. This is likely to surprise many shell scripts that believe that [0-9] is equivalent to [:digit:]. Is there some reason why these three values weren't specified after with the superscript characters? Note that the sort order need not be affected if this is changed, it that is a concern. P31, L1439: By specifying as the thousands separator in numeric output, you may make it difficult for shell scripts to create command lines for some utilities. (As an example, the POSIX.2 cut utility has a list option argument that is a or separated list of character or byte positions. If an application wanted to cut the first 1,100 bytes of each line of a file, in the C Locale this would be specified as: cut -b 1-1100 file In the locale presented in this paper, it would seem that this should be: cut -b 1-1,100 file but that could be interpreted by POSIX.2's cut utility as just byte 1 and byte 100 from each line, instead of bytes 1 through 1,100.