>network protocol standards (IL not withstanding), but it _did_ choose to fight >the POSIX/C99 et. al battle.
there are several different aspects to this: 1. the language accepted by the C compiler excluding the preprocessor and #include files 2. the C standard's include files 3. POSIX interface for (1), there are Plan 9-specific extensions (but then, there are gcc-specific extensions). more dramatically, Plan 9's compiler has its own simple pre-processor. i think it has helped keep the source tree relatively free of the horrible mess that cunning or clumsy use of the C preprocessor has made of other trees. i don't think there is currently a deliberate intent not to implement the basic C language as described in the standard. there are one or two significant differences. notably the compiler doesn't implement the value-preserving rules for comparisons. the rules in standard C are fairly awful (i'm thinking particularly of the dependency on the size of values). instead the compiler implements the older unsigned-preserving rule, if it implements any particular rule. still, the main reason not to implement value-preserving isn't aesthetic, but lack of time or effort on the one hand, and a slight worry that an explicitly `silent change' in C language semantics might break existing code in subtle ways. since most of the code has been compiled by other compilers, probably there wouldn't be a big problem, and the work, which is finite, should be done for completeness. for (2), one advantage of the Plan 9 #interface to libraries is that the #include structure is straightforward and reasonable (in the sense that one can reason about it). generally for one library (in particular the C library <libc.h>) there's one #include that must be included. declarations appear in exactly one #include file. the machine-dependent and machine-independent declarations are handled cleanly. none of those statements apply to ANSI C's stdlib/stddef/.../.../... mess. for (2) and (3), to allow programs to be imported, there's the APE environment, including (for (1)) options and commands to provide an ANSI-compatible C preprocessor. the usual reason that programs are hard to import (apart from ./configure, which doesn't actually do what it says), is that they are not ANSI/POSIX programs but (typically) gcc programs. so actually the problem is not that Plan 9 has an aversion to ANSI/POSIX but that everyone else has, differently, and as far as (1) goes, the source code is sometimes full of extensions and special attributes. perhaps they should consider standardisation?
