Thou shalt have no other gods before the ANSI C standard 1509

snip

Not what I was talking about at all. This is more what I would call "emergence of a 'best practice'".

I think I confused the issue by saying "a way of doing things" (which includes methods-methodologies, such as in your example) when I really meant, hm, something more static, such as a file format, or a protocol (TCP, HTTP, etc.), or a description of the syntax-semantics of a programming language. The common idea here is of a specification that allows (at least in principle) a variety of implementations and makes it possible for those different implementations to interoperate. (E.g., a C program that conforms to a particular standard (specification) for the language can be compiled by any compiler that conforms to that standard.)

Some such specifications-standards arise as a result of deliberate discussion and-or have been blessed by some organization that people trust to come up with rules for everyone to play by. There are at least a couple of C standards (C89? C90?) in this camp. I'm not sure of details, but probably someone here can supply them if it seems important. Whether a particular C program, or C compiler, actually adheres to one of these standards is another question, but at least there *are* standards not too closely tied to one implementer.

Other specifications-standards .... "just grow", I guess, and are widely adopted and buttumed by their adopters to indeed *be* standards that everyone adheres to. These are the "de facto standards" I'm talking about. Some things that distinguish them from real standards is that they lack the kind of official blessing that would make critics shut up and cope, and they don't necessarily have a detailed and authoritative specification publicly available, and there's a certain amount of controversy about whether they really should be standards everyone adopts. HTML-ized e-mail might be another example of something that's moving toward being considered a "de facto standard".

I'm still not happy with how I'm saying this, and I'm not even sure I have a clear idea of what I'm trying to say, but maybe this clarifies a bit.

My point is that once MS has started shipping Version XYZ of Office, whatever file formats it uses become a "de facto standard" -- meaning that it will be widely buttumed that if you send a file in one of these formats to any other computer user, that person will be able to "open" it (access its contents in a meaningful way). The fact that the only people of whom this is 100% true are other users of Version XYZ of Office is irritating for those who *don't* use this product, but if there are few enough of them compared to those who do, well .... "de facto standard". Whether MS makes public any kind of specification that other potential implementers could use is only relevant in that it makes it pretty much impossible to regard these file formats as "standard" in the sense we'd like to use the term (blessed by some organization, available as a way for different systems to interoperate, etc.). But a "de facto standard" as I mean the term doesn't require that.

Neither do I.

I'm not sure I'm entirely clear on what you mean by bit flows, but I suspect it's tangential to what I'm talking about here.

But if we started talking about what I'd call "best practices" (which would include ways of avoiding buffer overruns), that discussion would have something to do with "bit flows" ....

-- B. L. Mbuttingill ObDisclaimer: I don't speak for my employers; they return the favor.