Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!mimsy!umd5!brl-adm!brl-smoke!gwyn From: gwyn@brl-smoke.ARPA (Doug Gwyn ) Newsgroups: comp.lang.c Subject: Re: Some questions about ANSI C Message-ID: <6240@brl-smoke.ARPA> Date: Fri, 7-Aug-87 08:47:04 EDT Article-I.D.: brl-smok.6240 Posted: Fri Aug 7 08:47:04 1987 Date-Received: Sun, 9-Aug-87 00:47:52 EDT References: <497@houxs.UUCP> Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) ) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 134 Keywords: underscore Paris standard C declarations In article <497@houxs.UUCP> daw@houxs.UUCP (D.WOLVERTON) writes: >1) I read recently (in the C Journal?) that the name space available > to users might be increased to include some identifiers which begin > with an underscore. Has this been discussed by the Committee? In the Boulder meeting, it was decided to reserve to implementors the names _* for externals, _[A-Z_]* for all. This essentially reserves to applications the names _[a-z]* for non-externals, such as structure member names, macros, etc. >2) Is a report forthcoming regarding the results of the Paris meeting? > [Perhaps from Doug?] I wasn't at the Paris meeting, but I recently received the minutes, so I can (unofficially) summarize significant decisions, which I'll do at the end of this article. For more information, check the C Journal or other trade publications. >3) What is the current timetable for standardization? It is desired to have the next draft ready for the second public review by the end of the September meeting, but there is considerable doubt that it can be wrapped up by then. The intention is for the second public review draft to be technically solid enough that no substantive changes will be required as a consequence of the second review. Of course, if it happens that a serious problem is uncovered, it will be fixed; I don't recall whether that would necessitate a third review but we're hoping to avoid the delay that would cause. In any case, the second review draft should be prepared by the end of 1987, and would go out for public comment officially a month or two after it is approved. Therefore you should be able to get a review copy either around November 1987 or February 1988, if all goes as planned. After responses are prepared to the second review (which would take at least one, probably two more quarterly meetings), assuming there were no substantive changes the final standard would be submitted to X3 etc., which means that the form of the final standard would be known precisely (although perhaps available only through unofficial channels for a while) in the second half of 1988. At least, that's my personal estimate. >4) dpANSI C, as I read it, requires that a conforming hosted implementation > contain *no* declarations (including prototypes) or #defines for > user-space identifiers not defined by the Standard, in order to avoid name > space pollution. This implies that declarations for library functions > supplied by an implementation but not defined by the Standard which > currently exist in one of the standard headers must be moved elsewhere. > Where does the Committee or P1003 (POSIX) plan to put these gypsy > declarations? Won't this break existing (UNIX application) code? The name space collision issue is very important, and is one of the things I hope to address at the October Berkeley POSIX workshop. I won't go into all the gory details, but the outcome is, yes, the implementation must not interfere with the application's freedom to use names that the standard does not dictate or reserve for the implementation. However, this is not quite as severe as it would at first seem. For example, additional <> headers can be provided, and extra C library functions and extern data can be provided -- so long as the implementation of the X3J11-mandated functions does not itself use them (it could, however, follow my lead and have fopen() call _open() rather than open(), the latter of which could be provided to support applications that want to use it). The point is, an application must be perfectly free to define and use its own open(), gethostbyname(), etc. functions without breaking the semantics of the library routines. Insufficient care has been paid to this in the past, but now that we (almost) have standards, we need to fix our implementations. A POSIX implementation could also use an additional library, although this is not necessary (nor, in my opinion, desirable). ----- Paris X3J11 meeting results (unofficially extracted from minutes): Larry Rosler turned over the job of redactor to Dave Prosser. The requirement that file levels statics have "static" attached to their first appearance was reaffirmed. Library headers must be included only outside of declarations. Freestanding environments must support all C source characters in the target character set. Hexadecimal escape sequences \xhhh may contain an arbitrary number (1 or more) of hex digits. Funny characters in #include and #line file names have undefined effect. Structs, unions, and enums match across different translation units if all their members match (including names). Setjmp must be a macro. Storage class not first in a declaration is "obsolescent". %0 for zero fill in *printf() is no longer obsolescent. Macro for largest permissible filename to be added to . Representation for enums is implementation-defined. Bill Plauger's proposal for minimal support for multi-byte characters (via a letter_t typedef, a few new functions, and some slight wording changes) was approved in principle, wording to be arranged. This is much less of a change to the existing draft than alternative proposals such as mine, but indications are that it will be enough to satisfy the Japanese who rejected the draft because of the lack of some such facility. X3J11 finally admitted that there was no guaranteed "safe" limit to the size of the converted string produced by strxfrm(), and suitable revisions to its specs were made. Sense of the committee was that some way should be provided to save/ restore tailored/partial locales, but no motion was passed. Ditto that parentheses should force grouping, motion needed. Ditto that currency locale (not yet approved) should be empty for the "C" locale, not US$. Aliasing restrictions: An lvalue must match the type of the object it accessesm or the type with or without the unsigned attribute, or the type of an aggregate that contains the type, or be of a char type. It was noticed that the draft allows assigning to a struct containing const members, but no fix has yet been decided. There were numerous other, comparitively minor, changes and edits, and several proposals were discussed and rejected. The list above is simply the things I decided were worth mentioning here. Reminder: I am not an official spokesthing for X3J11.