Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!husc6!cmcl2!brl-adm!brl-smoke!gwyn From: gwyn@brl-smoke.ARPA (Doug Gwyn ) Newsgroups: comp.lang.c Subject: Re: Structure pointer question Message-ID: <8131@brl-smoke.ARPA> Date: 21 Jun 88 12:36:49 GMT References: <361@teletron.UUCP> <8074@brl-smoke.ARPA> <718@vsi.UUCP> <723@vsi.UUCP> Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB)) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 21 In article <723@vsi.UUCP> sullivan@vsi.UUCP (Michael T Sullivan) writes: >Note the leading underscore in the name-macro _HEADER_H. This keeps >your namespace from being polluted. Be careful! That identifier is reserved for use by the (ANSI) C implementation and should not be used by applications. In a large application we're currently developing, there are many functional "packages", each of which has its own 2-letter prefix which is used for all external identifiers in the package, as well as all macros defined in the corresponding interface definition header. So, for example, our header "Dx.h" uses the name "Dx_HDR_INCLUDED" for its one-time lockout flag. This package prefix scheme also addresses the problem of namespace partitioning, and has been working out quite well. >This type of thing sure would be handy in the Unix header files (hint, hint). A start had already been made at doing this, and it is essential for ANSI C conformance. (The C implementation will have to use macro names starting with underscore for its lockout flags.)