[RamiK]

I'm thinking about the pre-processor not supporting #if and the requirement for function prototypes.

I suppose the extension you have in mind are the extra libraries for dealing with buffered io, unicode and concurrency. But I don't think those could be termed "PLAN 9 own standard of C".

To clarify, my idea of restricted was in the sense of a highly refined subset. Much akin to how one should use C++ for instance. A careful selection of the good parts in C. Essentially, I was paying a complement to Plan9. :)

[4ad]

There are language extensions, mostly related to embedding structs (which made it in Go) and a new storage class, not only new libraries.

Please see section 3.3: http://doc.cat-v.org/plan_9/4th_edition/papers/compiler

[RamiK]

Extensions don't break standard compliance so I didn't bring them up. Note that both C++ and GNU C have similar extensions but under different semantics which don't make them any less ANSI compliant.

BTW, be careful around those documents. The assembler, compiler, parser and linker have seen over two decades worth of work since those were put ink to paper. Though admittedly I haven't read through the lib9 source tree in years...

[4ad]

> Extensions don't break standard compliance so I didn't bring them up.

Sure they do, by definition code that uses the extensions is not standards compliant. Plan 9 C code makes heavy use of Plan 9 extensions. The Go runtime also makes use of those extensions, that's why gcc recently (2009) implemented -fplan9-extensions in order for gccgo to compile the Go standard library.

> Note that both C++ and GNU C have similar extensions but under different semantics which don't make them any less ANSI compliant.

I think what you mean is that GNU C is a strict superset of ANSI C and you assume that Plan 9 C is the same. This assumption is wrong. Plan 9 C is not a superset of ANSI C, some ANSI C things are missing; e.g. const. That being said it's not that hard to compile C89 code with the Plan 9 C compilers.

> be careful around those documents. The assembler, compiler, parser and linker have seen over two decades worth of work since those were put ink to paper.

I should know since I use Plan 9 every day and I recently ported the Go toolchain to Solaris and gave a talk on these tools. The compiler document is very accurate, the only glaring anachronism is that the extern register storage class doesn't necessarily use a register in the Go toolchain, but depends on the target operating system. It's still true on Plan 9 though. The assembly guide is more inaccurate, but the C papers are accurate, at least for now.

[RamiK]

> Sure they do, by definition code that uses the extensions is not standards compliant.

I don't follow. How's having non-standard complying code taking advantage of the extensions offered makes the compiler itself any less standard capable? I was under the impression being standard compliant didn't mean forbidding extensions... But I suppose I could have been mistaken. :(

> GNU C is a strict superset of ANSI C...

In the same way that I said "Plan 9's C is a restricted ANSI C variety". Yes. It takes some good stuff from ANSI C and leaves some unnecessary stuff out by default. Still, keeping to the standard.

> some ANSI C things are missing; e.g. const.

Surprisingly irrelevant. The draft actually said "If an attempt is made to modify an object defined with a const-qualified type through use of an lvalue with non-const-qualified type, the behavior is undefined.". So, regardless of what the Plan9 doc says about giving warnings and not implementing const in a standard confirming way, no behavior was ever expected in the first place by the standard so the compiler is unwittingly compliant :D And volatile follows suit...

My guess to why the standard requires to implement a keyword without specifying explicit behavior, is that they wanted backward-compatibility with some vendor compiler that did implement these but didn't want to force any actual functionality.

Mind you the standard is far more lax then most people give it credit: Even "void main()" and "exits(0);" that usually raise a few eyebrows are all implementation-specific according to the standard and thus are compliant.

> The compiler document is very accurate...

I was thinking about https://docs.google.com/document/d/1xN-g6qjjWflecSP08LNgh2uF... but I'm obviously not as versed as you in the state of the tool-chain so that's that I suppose. I personally did some work on getting the compiler to work on a MIPS router I had a few years back but my work was superseded by something better before I could even think about release so that was that... It was at a pretty late stage though with most of the assembly written down. So the impression I got at the time must have had mostly to do with the assembler. But that's ancient history I suppose.

So, from what I can tell out of the standard and the actual behavior of the compiler, it's complaint regardless of what it's docs say. More so, I can't think of a lot of non-confirming compilers I came across outside the embedded circles in recent years. Why, even MSVC is at most a custom header away per project away from compliance and since boiler-plate was never restricted it might as well be considered standard.

TL;DR Standards are highly overrated.