📄 c-iaq-a.html
字号:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "HTTP://WWW.W3.ORG/TR/REC-HTML40/STRICT.DTD"><HTML> <HEAD> <TITLE>Infrequently Asked Questions in comp.lang.c - Annotations</TITLE> </HEAD> <BODY> <H4><A NAME="meta"></A>Meta-Annotations:</H4> <P>This document was originally written as a morning's work in mid-March of 1995. The idea came from a vague idea I had about "correcting" the FAQ posting that year. When I started thinking of questions to which I could provide "corrected" answers, I realized I could do quite a lot of them - almost enough to do my own FAQ! The first section I wrote was "Null Statements", all of the others came later. However, perhaps 80% of the text you see here was, with minor alterations, written that morning.</P> <P>You'll notice that the IAQ is much shorter, and perhaps less informative, than the real FAQ. This is largely a result of laziness, but I don't think there's as much funny stuff to be written; already, this suffers from an excessive reuse of jokes.</P> <P>These annotations are intended to highlight and explain the jokes. You see, some people don't get them. One person corrected "errors" (some of them, in fact, were factually correct!) up through Chapter 7, pointing out at one point "you would have done better to leave this as a humorous non-answer"; apparently, the fact that they're <EM>all</EM> humorous non-answers had escaped him.</P> <H4><A NAME="intro"></A>Intro Annotations:</H4> <P>Starting from "Certain Topics", this is just word-similarity parody of the comp.lang.c FAQ.</P> <H4>Table of Contents:</H4> <P>Nothing to see but a link farm. Move along, move along.</P> <H3><A NAME="section-1"></A>Section 1: Declarations and Initializations</H3> <P>Several of the jokes in this section are snide comments about the horribly stupid rules people use, and even write up in books, for how to choose data types, and some of the misconceptions people have about them. <P> <H4><A NAME="question-1.3"></A>1.3</H4> <P>Of course, the joke here is that the encoding for the character set (thus, the representation of character constants such as <CODE>'i'</CODE>) has nothing to do with the location of objects with a given name. This question has garnered more "corrections" than any other; typically, it's the first really obviously wrong answer that people see, but if they're going to see a funny answer and not get the joke, this is the one. Of course, the <EM>conclusion</EM> reached is correct - outside of structures, there's no ordering at all to variable declarations, and even inside structures, there can be arbitrary padding between members.</P> <H4><A NAME="question-1.4"></A>1.4</H4> <P>The rule proposed is precisely backwards; definitions are what conflict with each other, while multiple compatible declarations are allowed. Most programmers like being able to include a header once in every module, at the very least - which is what's prevented by having multiple definitions.</P> <H4><A NAME="question-1.5"></A>1.5</H4> <P>Subtle point: In many implementations, the program will <EM>compile</EM> without errors - it's only the "link" phase (translation phase 8, to the pedants) which fails when no object named <CODE>bar</CODE> can be found. The remark about assigning bar a value is a reference to the difference between a declaration (such as "<CODE>int bar;</CODE>"), which is compatible with another, external, definition, and a definition (such as "<CODE>int bar = 5;</CODE>") which reserves storage. <P> <H4><A NAME="question-1.7"></A>1.7</H4> <P>Several jokes in here. The first is the one about Microsoft inventing C. Microsoft is often credited with inventions they had nothing to do with; I just wanted to be a joiner. I once posted a URL for this question in part of a Usenet discussion, along with a paragraph (in the Usenet post) crediting Microsoft with the invention of "the separation of Church and State". Despite this, I got angry corrections from people who didn't like Microsoft.</P> <P>The code is subtly wrong in many ways. Apart from the subtle type mismatch (printf's first argument is <CODE>const char *</CODE>), the second example is completely wrong; a function name without ()'s to indicate calling is just an expression, which is discarded. This is the real reason the function pointer is only called through in the first example. The comment about ls is completely irrelevant.</P> <H4><A NAME="question-1.9"></A>1.9</H4> <P>This is obviously complete nonsense, although it would likely work on some system somewhere. Of course, it would lead to a huge amount of casting which shouldn't be necessary at all. A more traditional solution would be to separate the typedef out from the struct declaration, and put the typedef first, or alternatively, to name the struct and spell its name out in the declaration of the pointer-to-next-item.</P> <H4><A NAME="question-1.10"></A>1.10</H4> <P>Well, actually, regular ints can be entered using hexadecimal notation, and the example given shows octal (but is correct, because after all, octal <CODE>07</CODE> and hex <CODE>0x7</CODE> are the same value.)</P> <H4><A NAME="question-1.11"></A>1.11</H4> <P>For about two years, there was an imbalance in the huge expression; I had a square bracket matched with a parens. One of the "corrections" I got was a suggestion that this huge expression would be more readable if I used typedefs to build it. Obviously, this construction is completely wrong; it's done wrong-way-out, and then some. The "mirrors" comment is just a remark about the constant abuse of the phrase "declaration reflects use". (Which is actually a fairly accurate model; the idea is that, if I declare "<CODE>int *ip</CODE>", that "<CODE>*ip</CODE>" will have type "<CODE>int</CODE>". Thus, declaration ("<CODE>*ip</CODE>") reflects use ("<CODE>*ip</CODE>").)</P> <H3><A NAME="section-2"></A>Section 2: Structures, Unions, and Enumerations</H3> <P>This section has no cohesive structure; it's pretty much just a collection of really bad answers to questions from the real FAQ. <H4><A NAME="question-2.2"></A>2.2 </H4> <P>Obviously, Ritchie developed C long before he wrote the book, and he worked at Bell Labs all along. The "video game developer" is a reference to the story that Unix evolved from a "space war" game developed by Thompson. </P> <H4><A NAME="question-2.3"></A>2.3</H4> <P>Once again, just plain nonsense. Of course, the caveat is correct for some systems, by sheer coincidence. Structs passed on the stack were once fairly risky because some systems had very limited stack space. </P> <H4><A NAME="question-2.5"></A>2.5</H4> <P>The idea is that, since all output occurs "as if by successive calls to fputc", and putchar is really very similar to fputc... Of course, this is nonsense. The line about the sign bits is just noise; I wasn't referring to anything in particular, except perhaps the general paranoia about signed types that I tend to have. </P> <H4><A NAME="question-2.6"></A>2.6</H4> <P>A surprisingly good rule, for how stupid it is. This is a side effect of the "all the world's a 32-bit machine" fallacy. </P> <H4><A NAME="question-2.9"></A>2.9</H4> <P>The gimmick here (related to 2.6's 4-bytes-per-object joke) is that the size of the union will almost always be the size of the largest member (8 bytes is common on many systems), which happens to be the sum of the logical sizes of the other members. At least one reader pointed out that this code could never be expected to work; most astute. </P> <H4><A NAME="question-2.10"></A>2.10</H4> <P>Mr. Reagan (U.S. President, 1980-1988) fired a number of air traffic controllers who went on strike (which their contracts, plausibly, prohibited). </P> <H4><A NAME="question-2.11"></A>2.11</H4> <P>C9X actually offers a way to do this, with the very similar <CODE>(struct foo) { 3 }</CODE>. </P> <H3><A NAME="section-3"></A>Section 3: Expressions</H3> <P>Of course, most of these are jokes about the meaning of undefined behavior.</P> <H4><A NAME="question-3.5"></A>3.5</H4> <P>The point here is that the comma operator creates sequence points, and, because it has such a low precedence, it tends to have very powerful control over otherwise confusing expressions. Of course, it makes them just as confusing... but that's okay.</P> <H3><A NAME="section-4"></A>Section 4: Null Statements</H3> <P>This section is mostly phrasing-similarity games with the FAQ's section on null pointers. Null statements are probably nearly as misunderstood, simply because they're rarely used.</P> <H4><A NAME="question-4.2"></A>4.2</H4> <P>The line about the FDA refers to the "side-effects" of drugs; a completely different meaning of "side-effects".</P> <H4><A NAME="question-4.3"></A>4.3</H4> <P>"All bits zero" is a reference to the common belief that a "null pointer" is a pointer with a machine representation consisting entirely of zero bits.</P> <H4><A NAME="question-4.5"></A>4.5</H4> <P>I can't resist a chance to dig at C++'s vast collection of features which probably wouldn't have survived except that someone had existing code...</P> <H4><A NAME="question-4.8"></A>4.8</H4> <P>More utter nonsense derived from common misunderstandings. In particular, it's not clear what "segment bits" are supposed to be, and it doesn't matter whether or not there's a stray value in a statement that doesn't do anything.</P> <H4><A NAME="question-4.9"></A>4.9</H4> <P>If you follow the first two rules, you'll probably be okay. The line about "the author of the FAQ, or the moderator of the group" refers to the fact that I was posting this to comp.lang.c.moderated,⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -