Coding standards

[Natt Serrasalmus]

After years of operating without any coding standards whatsoever, the
company that I recently started working for has decided that it might be a
good idea to have some. I'm involved in this initiative.

Typically I find that coding standards are written by some guy in the
company who has a way of coding that he likes and then tries to force
everybody else to write code the way he likes it, not for any rational
reason, but simply for the subjective way he likes it. I think this is
wrong.
This is particularly irksome when it comes to issues of code layout style
which has very little relevance to the execution of the code or the
readablility and maintenance of the code.

I also think it is wrong for coding standards to try to prevent idiots from
doing stupid things. No matter how stringent some standards are, somebody
stupid is going to find a way to do something stupid to the code. My point
is that instead of making the standard more restrictive on good coders, the
bad coders should be brought up to speed to be able to write good code, not
pandered to by the standard. For example there is the seemingly universal
attitude that fully bracketed
syntax is the way to go (this will stop the idiots). I strongly disagree.
There are many times that leaving out the braces where not necessary makes
for more readable code. It also reduces the maintenance of braces; the fewer
braces the easier it is to keep braces matched up. The problem is that I
think most coders are too lazy to be bothered to know exactly when they need
braces and when they don't. If you don't know, just stick them in everywhere
that it can't hurt. Lots and lots of braces means lots and lots of code to
maintain that doesn't need to be there.

I recently read a standard that prohibited use of the ternary (conditional
?) operator. I find that most C programmers just haven't bothered to learn
how to use it and don't want others to use it, because then they'll have to
figure it out. However I have also found that in most cases where it is
used, it can make the code much clearer even for those who are not
accustomed to its use.

a = (b == c) ? d : e;

Is just as understandable and more maintainable than

if (b==c) {
a = d;
}
else {
a = e;
}

In the first case it is obvious in one line that you are simply assigning a
value to a based on the condition. The use of the if statement makes for a
lot more code that is subject to error in maintenance.

Another issue that I have come across is the one way out of a function
issue. I contend that if there are conditions that warrant an earlier exit
from a function then the early exit should be taken. For eample:

int funct( int arg )
{

.....

if (condition) return ERROR;

....

return OK;

is much better than

int funct( int arg )
{
int retval = ERROR;
.....

if ( !condition) {
retval = OK;
(rest of function);
....
} /* end of if ( !condition) */

return retval;

In the first case you've been very clear as to what values are going to be
returned, you've reduced the number of braces involved and you've reduced
the indentation level of the major part of the function. The argument
against this is that there may be some clean up that needs to be done in a
function and this style may lead an idiot to exit the function with out
doing the clean up. My rebuttal is that number one, only a small minority of
functions have the requirement that the clean up be done before exiting the
function. Number two, the clean up should be a separate function anyway that
can be called from anywhere in the parent function and number three you just
can't count on the standard to protect the code from idiots anyway so why
pretend that it does?

A similar issue is this one:

if (condition) {
retval = func(arg );
}

If that condition has to be tested before each function then the condition
should be evaluated by the function instead:

retval = func( arg, condition);

....
int func( int arg, BOOLEAN condition)
{

if (!condition) return OK;

....
}
On the whole I consider less code to be more maintainable than lots of code.
Anywhere I can reduce the lines of code then that makes it easier to
maintain. For example:

if( condition)
{
retval = func( a, b);
}
else
{
retval = func( a, c);
}

if (retval != OK)
{
error_exit_func();
}

a much better way is

if ( !func(a, condition ? b : c ) error_exit_func();
Is there anybody out there who will agree with me on these issues or am I
the lone voice for this type of coding?

[Keith Thompson]

jd*********@yahoo.com writes:

Michael Wojcik wrote:

Please provide proper attributions when you quote on Usenet.
For someone so concerned with imposing consistency, you're
observing rather poor netiquette.
Sorry. I often omit the attribution when the quote is
a paraphrased or consensus opinion, of limited relevance,
simply for context, or even in the interest of brevity.

If you paraphrase, you're not quoting, and you should clearly indicate
that you're paraphrasing. You should also indicate whose words you're
paraphrasing. But it seldom makes sense to do so anyway, since
quoting directly and accurately is easier.

Here's a hypothetical example:

| Fred Foo writes:
| > Here's a long-winded explanation of some concept or other.
|
| So you're saying that we should just avoid it altogether?

By providing both a direct quote and a paraphrase, you let your
readers see the actual context and judge whether your paraphrase is
accurate.

If you want to make a statement of your own without referring to what
someone else has written, just make the statement; if there's no
quotation, there's no need for attribution.

As for omitting the attribution for other reasons, please don't do
that. An attribution is just a line or two, and omitting it is just
rude, even if you don't mean to be rude.
Please note that readers who need the source can easily find
it, e.g. at Groups.Google.
Yes, I can switch from my newsreader to my web browser, go to
groups.google.com, figure out how to search for your article, and then
come back to my newsreader. Or you can include the attribution and
save each of us the effort of doing that dozens of times a day for
multiple articles.
(Also posting at both Groups.Google
and Groups-Beta.Google seems to be broken these days. I
had to cut and paste to get the remark and attribution above.
Suggestions welcome, but be aware I post from Internet cafe.)
Yes, groups.google.com has some problems. If you click on "Reply"
while viewing an article, it gives you a tiny text box and no way to
quote the article to which you're replying other than manual
cut-and-paste. But if you click on "show options" and then click on
the "Reply" that appears below the article headers, you get a larger
text box with the article properly quoted, including an attribution
line. It's not surprising that a lot of people miss that.
Also, to avoid disharmony, I often omit the attribution for a quoted
idea when I argue against the *idea*, but not against the ideator.

Again, please don't do that. If you want to disagree with something
I've written, that's fine (especially if you're right), but do me the
courtesy of acknowledging who made the statement you're arguing
against. I scan articles for my own name so I can see which
discussions I've participated in. If you omit the attribution, I
might miss a response and lose the opportunity either to explain why I
was right or acknowledge that I was wrong.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Michael Wojcik]

In article <11*********************@z14g2000cwz.googlegroups. com>, jd*********@yahoo.com writes:

Michael Wojcik wrote:

Please provide proper attributions when you quote on Usenet.
Sorry. I often omit the attribution when the quote is
a paraphrased or consensus opinion, of limited relevance,
simply for context, or even in the interest of brevity.

You can, of course, do as you please in this regard - none of us
can force you to do otherwise (practically speaking). However,
this practice is idiosyncratic and opposed to what passes for
official consensus on good Usenet practice (eg Son-of-1036 and
its successor Internet-drafts).
Please note that readers who need the source can easily find
it, e.g. at Groups.Google.
Not necessarily. Google Groups is not always available; it may
not have received all the relevant articles when the reader
searches it; the reader may be using a system where searching
Google Groups is difficult or impossible. At the very least it
will require switching to a different application, which is
cumbersome, for many readers.
(Also posting at both Groups.Google
and Groups-Beta.Google seems to be broken these days. I
had to cut and paste to get the remark and attribution above.
Suggestions welcome, but be aware I post from Internet cafe.)
Well, yes, this is both unfortunate and outside your control.
Google's Usenet interface continues to deteriorate. For a
company so keen on boasting of the prowess of their staff, they
are remarkably thick-headed.
Also, to avoid disharmony, I often omit the attribution for a quoted
idea when I argue against the *idea*, but not against the ideator.
That strikes me as decidely poor practice in any forum. It gives
your readers no recourse for identifying the source of the idea
you disagree with, and hence for discovering whether you are
representing it accurately and how its author may have supported
it. In short, it strikes me as distinctly unfair.
Speaking of harmony, let's please do avoid frivolous
objections or "straw-man" debates.
One man's frivolous objection may be another's compelling argument.
But if you *do* name the reference in an excerpt,
it is Netiquette to give quotee the benefit of his own
words. It is unreasonable to imply that jdallen2000
extrapolates a claim about the readability of
j } else {
to promote construction like
j char *s, *commap; int cnt;
j s = Begp; if (*s == '\0') return 0;
j for (cnt = 1; commap = index(s, ','); cnt++) {
j *commap = '\0'; plain_ups(s);
j s = commap + 1; while (*s == ' ') ++s;
j } plain_ups(s); return cnt;
Sure. However, I've no idea whom you're responding to.

with English, frequent misspellings eventually make their
way into the dictionary, but that doesn't make misspelling
right.

Your (understanding of English is flawed).

Hunh? What's your point?

My point is that your understanding of English is flawed; that
there is no universal foundation for establishing what consititutes
"right" and "wrong" usage of English.
Are you one of the guys that writes, "i saw the lite"?
No. I would guess that my knowledge of the conventions of English
usage, and cognate areas such as English grammar, is better than
that of most speakers; and my preference is to employ the conven-
tions usually preferred by those with similar expertise. (I hold
one degree in the field, and expect to be receiving another in
the near future.)
You seem to be from the laissez-faire school,
I fear you've misapprehended. I do not encourage novel, sloppy,
or inconsistent usage, generally speaking; but I recognize that
my preferences - popular though they may be with my peers - are
not law.
but your arguments shed more heet than lite.
I believe it showed that your analogy was flawed. If you believe
otherwise, I'd be glad to hear why.
I wrote:

[True Style] was in very widespread use among the most elite C
programmers. ... proud to emulate the style of so many Masters.
Someone responded, and I paraphrase:

No, this list of True Style programmers is not particularly
more or less skilled than [some other groups].

Really? Are you guys comparing yourselves to Bill Joy?

Some of us may be. I haven't completed a comprehensive study of
source he's produced, so I couldn't say. I have seen quite a bit of
C source produced by some of the regulars in this group that is
correct, portable, robust, clear, reasonably concise, and readable;
I'm not sure how your "Masters" could have improved on it.
The best C code I've examined has been Unix kernels, shells, etc.
I've seen good and bad there. In my youth I fixed quite a number
of bugs in the BSD 4.3 kernel and system utilities (BSD Mail was
particularly fraught, IIRC).
I also wrote:

Although defense counsel continues to recommend `indent'
they offered no rebuttal to this point:
Still, no one has deigned to post a rebutter here.

I'm afraid I don't use indent. When I maintain code, I maintain its
style as well. Reformatting poses too great a challenge to source
code control systems and the like.
Which of the following is more easily read?
Do be open-minded, setting aside any convention.

Both your style (with the three "for" statements at the same level of
indentation) and the one you call "approved" seem perfectly readable
to me. I have no argument with deviating from conventions of style
for special cases. But that is because I don't believe conventions
of style have any special intellectual, social, or metaphysical force.
They are just conventions.

--
Michael Wojcik mi************@microfocus.com

But I still wouldn't count out the monkey - modern novelists being as
unpredictable as they are at times. -- Marilyn J. Miller

[Default User]

Michael Wojcik wrote:

In article <11*********************@z14g2000cwz.googlegroups. com>,

jd*********@yahoo.com writes:

(Also posting at both Groups.Google
and Groups-Beta.Google seems to be broken these days. I
had to cut and paste to get the remark and attribution above.
Suggestions welcome, but be aware I post from Internet cafe.)

Well, yes, this is both unfortunate and outside your control.
Google's Usenet interface continues to deteriorate. For a
company so keen on boasting of the prowess of their staff, they
are remarkably thick-headed.

While the google interface leaves much still to desire, jdallen's
contention is false. I am, right now, posting through google. You can
see that proper attributions and quoting is available.

The problem is that it's not obvious how to do this. The Reply button
at the bottom of the post is not the one to use. Rather, the Show
Options button should be clicked, revealing a set of buttons previously
hidden. The Reply there works as expected.

Why google chose the plain Reply as the default I can't say. It was a
BAD decision. It's led to a rash of people posting in violation of
basic netiquette, not because they want to but because they can't
figure out how to do it correctly.


Brian

[E. Robert Tisdale]

Chris Croughton wrote:

E. Robert Tisdale wrote:

K&R refers to only to ; as a statement terminator.
Perhaps, but it isn't relevant.
The question mark, colon, comma and semicolon
are English punctuation marks first.

So is dot (period, full stop).

English uses the same glyph for both period and decimal point.
If I were writing C programs using
English punctuation rules I would write:

x = a. b? fred. bill + joe: foo. bar;
That's a bad analogy. The member selection operator
resembles a decimal point in placement and function
and therefore should have no leading or trailing white space.
(it is conventional typography to put two spaces after a terminator
but that looks even sillier).

For that matter, ! is also a terminator in English,
Do you also write (! a)?
No.
But I might write (a! ) if C had defined not
to be a postfix instead of a prefix operator.
Spanish exclamations may begin with an [upside-down] exclamation point
but English exclamations never do.
And, I believe the rule in ordinary Spanish typesetting is that
*no* space appears between the [upside-down] exclamation point
and the beginning of the exclamation.
Do you put the terminator inside the quotation marks
as style guides for English say you should?
I thank the gods (particularly God Ritchie and God Kernighan)
that I don't have to maintain your code...

They are used as terminators in ordinary English.
Which is irrelevant, I am writing C not English.

C doesn't specify whitespace around any punctuation marks.
Evidently, you've made up your own style rules
which is fine as long as you're consistent.
People who read and maintain a lot of your code
will eventually become habituated to your style.
But I think that it's easier for other people to read my code
because I follow standard ordinary English [mathematical]
typesetting rules.

The fact that they may be used to represent operators
in C programs should not matter.
I think that C programs are more readable
if they follow the same rules that are used
in ordinary [mathematical] typesetting.

They don't mean the same thing
(what do ? and : mean in mathematical typesetting anyway?).

They are punctuation.
Certainly = doesn't mean the same as it does in mathematics
(something which trips a lot of mathematics students
when learning programming).
This is a design flaw in the Fortran and C programming languages.
Pascal uses := for the assignment operator.
I would prefer <--.
But, in any case, there should be [at least] one whitespace
before and one white space after the assignment operator.
Nor does ^ have its conventional meaning of exponentiation.
I am aware of no such convention.
C is not English. C is not mathematics. Different languages --
even Real World(tm) ones, have different conventions for typography.
Live with it...

C doesn't have *any* rules
for white space around operators and other punctuation.
Live with it.

If you want to make up your own rules, go ahead.
But don't that expect other programmers will find your code
easier to read, understand and maintain.
I am only suggesting that
other programmers might find your code easier to read
if you used a style that they are likely to be familiar with
like ordinary English [mathematical] typesetting.

[Lawrence Kirby]

On Tue, 04 Jan 2005 22:34:49 +0000, Chris Croughton wrote:

On Tue, 04 Jan 2005 21:26:42 GMT, CBFalconer
<cb********@yahoo.com> wrote:

As far as I am concerned, multiplicative has precedence over
additive which has precedence over logical will do. Anything
further should be explicitly indicated with the use of the all
purpose parentheses. The mere existence of further levels in C is
a fault IMNSHO. Yes, I know there are no precedence levels in C,
just Backus-Naur descriptions.
I've tried to write a precedence-based parser for C expressions. It's
all fine apart from the ternary operator, as far as I could determine
nothing makes that come out right (I tried all combinations of left and
right precedence, and none gave the right answer for a ? b ? c : d : e).

Odd. There's no ambiguity here, there's only one possible way to parse it
so precedence is not relevant. In that respect it is similar to a[b[c]]
Which was annoying since I did not want to use a top-down BNF parser for
it. I eventually 'solved' it with a hack which did special things with
the ternary operator...

The conditional operator IS right associative in the sense that
a ? b : c ? d : e is parsed as a ? b : (c ? d : e) and
not (a ? b : c) ? d : e

Lawrence

[Chris Croughton]

On Mon, 10 Jan 2005 18:32:57 +0000, Lawrence Kirby
<lk****@netactive.co.uk> wrote:

On Tue, 04 Jan 2005 22:34:49 +0000, Chris Croughton wrote:

I've tried to write a precedence-based parser for C expressions. It's
all fine apart from the ternary operator, as far as I could determine
nothing makes that come out right (I tried all combinations of left and
right precedence, and none gave the right answer for a ? b ? c : d : e).

Odd. There's no ambiguity here, there's only one possible way to parse it
so precedence is not relevant. In that respect it is similar to a[b[c]]

OK, so what (numeric or relational) precedence do you give ? and : on
the left and right?

Which was annoying since I did not want to use a top-down BNF parser for
it. I eventually 'solved' it with a hack which did special things with
the ternary operator...

The conditional operator IS right associative in the sense that
a ? b : c ? d : e is parsed as a ? b : (c ? d : e) and
not (a ? b : c) ? d : e

But my example was a ? b ? c : d : e. The problem is that although
visually (or with a top-down parser) it is not ambiguous, with a
bottom-up parser based on numerical precedence it doesn't (as far as I
could tell) produce the right answer in all circumstances. It generates
oddities like (a ? (b ? c) : (d : e)).

Chris C

[Richard Bos]

infobahn <in******@btinternet.com> wrote:

Richard Bos wrote:

infobahn <in******@btinternet.com> wrote:

I would not judge the competence of a C programmer by his ability to
remember a couple of facts from p53.

Well, no; most of us don't need to know about universal character names,
after all.

That's most amusing. I can't believe a man of your calibre doesn't
know the precedence table on p53 of "The C Programming Language",
2nd edition.

I know it exists. I don't tend to remember page names. (And, as you
know, it isn't normative; only the Standard is.)

Richard

[Richard Bos]

Chris Croughton <ch***@keristor.net> wrote:

<E.**************@jpl.nasa.gov> wrote:

The question mark, colon, comma and semicolon
are English punctuation marks first.

So is dot (period, full stop). If I were writing C programs using
English punctuation rules I would write:

x = a. b? fred. bill + joe: foo. bar;

(it is conventional typography to put two spaces after a terminator,

Not anywhere else but in the USA, it isn't; and even then, not in
professional typesetting. Note that K&R was _not_ professionally
typeset: TeX gets this wrong.

Richard

[infobahn]

Richard Bos wrote:

infobahn <in******@btinternet.com> wrote:

<snip>

I can't believe a man of your calibre doesn't
know the precedence table on p53 of "The C Programming Language",
2nd edition.

I know it exists. I don't tend to remember page names.

Numbers.
(And, as you
know, it isn't normative; only the Standard is.)

Yes, you're right; I did know that. I also know that the Standard,
whilst undoubtedly an excellent and indeed uniquely authoritative
definition of the language, makes a lousy tutorial. It's not even
much use as a reference, since I have bought just the one copy and
have no intention whatsoever of printing it out and carrying the
resulting half-ton of paper everywhere I go. (I am, however,
considering transferring it to a memory stick. That would be
quite handy.)

So I use K&R as my day-to-day reference. It's unlikely to betray
me except in odd corners of the language which I'm unlikely to use
anyway. And yes, p53 is well-worn. Of course, I don't need that
information when I *write* code; only when I read it.

The use to which the Standard appears to be most commonly put is
as a stick to beat people with; this is a great shame.

[Chris Croughton]

On Tue, 11 Jan 2005 16:04:29 GMT, Richard Bos
<rl*@hoekstra-uitgeverij.nl> wrote:

Chris Croughton <ch***@keristor.net> wrote:

<E.**************@jpl.nasa.gov> wrote:

> The question mark, colon, comma and semicolon
> are English punctuation marks first.
So is dot (period, full stop). If I were writing C programs using
English punctuation rules I would write:

x = a. b? fred. bill + joe: foo. bar;

(it is conventional typography to put two spaces after a terminator,

Not anywhere else but in the USA, it isn't;

In the UK it has been for the last 40 or so years, unless they've
changed it recently (of course, almost all typesetting is done in
proportional fonts now so it isn't obvious). It was certainly that way
for dissertations when I took my degree (University of Kent at
Canterbury, UK, 1978).
and even then, not in professional typesetting. Note that K&R was
_not_ professionally typeset: TeX gets this wrong.

In professional typesetting, the post-terminator gap was still greater
than the inter-word one (how much greater depends on the typesetters).
But it was usually proportionally spaced, and so less noticable.

Chris C

[infobahn]

Chris Croughton wrote:

On Tue, 11 Jan 2005 16:04:29 GMT, Richard Bos
<rl*@hoekstra-uitgeverij.nl> wrote:

Chris Croughton <ch***@keristor.net> wrote:

(it is conventional typography to put two spaces after a terminator,

Not anywhere else but in the USA, it isn't;

In the UK it has been for the last 40 or so years, unless they've
changed it recently (of course, almost all typesetting is done in
proportional fonts now so it isn't obvious).

The whole point of the two spaces was an attempt to get around the
inflexibility of fixed-pitch fonts. In the days before proportional
fonts existed (which, from my perspective, would have been 1990 or
before, although of course other people here will undoubtedly have
encountered them much earlier than that), I always left two spaces
after a full stop. When I encountered proportional fonts, I realised
immediately that this rather unnatural practice was no longer
necessary (because the word processor logic would, or at least
*should*, be able to sort out the right amount of space to leave at
the end of a sentence), so I stopped using the second space whenever
I was using proportional fonts... and I seem to have stopped using
it with fixed pitch fonts too!

[Chris Torek]

In article <11*********************@z14g2000cwz.googlegroups. com>
<jd*********@yahoo.com> wrote:

... I've not examined much of Chris Torek's
code but he'd qualify: what style does he use?
Within limits:

- for existing code, the style in the code being maintained or
extended; or

- for new code, the mandated corporate (or, in earlier days,
academic) style, if any; or

- the style I personally prefer.

The style I most *prefer* is largely that of the 4.xBSD systems (x= 3), with indentation at either four spaces or one DEC-VT100-style-tab

(i.e., 8 spaces). Full-tab indents are a bit large, and in code
I post here, I use four-space indents:

/*
* Block comment describing f()'s raison d'etre, parameters,
* and so on.
*/
int f(char *arg1, int arg2) {
int localvar;
/* other declarations */

/* one blank line between declarations and code */
code();
if (expr) {
code();
controlled();
by();
if_expr(); /* rhs comments are rare but do occur */
} else
otherwise();
return 42; /* RIP DNA [frivolous comments occur :-) ] */
}

This style can (mostly) be produced via indent (either the old
net.lang.c-era version, or, with more options, GNU indent).
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[E. Robert Tisdale]

Chris Torek wrote:

jdallen wrote:

... I've not examined much of Chris Torek's
code but he'd qualify: what style does he use?

Within limits:

- for existing code, the style in the code being maintained or
extended; or

- for new code, the mandated corporate (or, in earlier days,
academic) style, if any; or

- the style I personally prefer.

The style I most *prefer* is largely that of the 4.xBSD systems (x

= 3), with indentation at either four spaces or one DEC-VT100-style-tab

(i.e., 8 spaces). Full-tab indents are a bit large, and in code
I post here, I use four-space indents:

[snip]

You really don't need to store all of those space characters.
You can use tabs and set tab stops where you want them:
expand -t 4 f.c /*
* Block comment describing f()'s raison d'etre, parameters,
* and so on.
*/
int f(char *arg1, int arg2) {
int localvar;
// other declarations

// one blank line between declarations and code
code();
if (expr) {
code();
controlled();
by();
if_expr(); // rhs comments are rare but do occur
} else
otherwise();
return 42; // RIP DNA [frivolous comments occur]
}

This style can (mostly) be produced via indent (either the old
net.lang.c-era version, or, with more options, GNU indent).

[Keith Thompson]

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> writes:
[...]

You really don't need to store all of those space characters.
You can use tabs and set tab stops where you want them:

[snip]

If you set tab stops to something other than 8 columns, the result
will be a text file that can't be viewed properly without filtering it
through "expand" or using a text editor with the proper settings (and
8-column indentation is too much for my taste).

Just use space characters; they don't take up enough room to be worth
worrying about.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Mark L Pappin]

rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:

Note that K&R was _not_ professionally typeset:
TeX gets [extra space between sentences] wrong.

You seem to be implying some causal relationship between these two
statements. My copy of K&R2 says "pic|tbl|eqn|troff-ms". No TeX
there.

mlp

[Richard Bos]

Mark L Pappin <ml*@acm.org> wrote:

rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:

Note that K&R was _not_ professionally typeset:
TeX gets [extra space between sentences] wrong.

You seem to be implying some causal relationship between these two
statements. My copy of K&R2 says "pic|tbl|eqn|troff-ms". No TeX
there.

No, I was simply misremembering. What I meant to say was that troff gets
this wrong. (I'll check Knuth this evening to see what TeX does).

Richard

[CBFalconer]

Keith Thompson wrote:

[snip]

If you set tab stops to something other than 8 columns, the result
will be a text file that can't be viewed properly without filtering
it through "expand" or using a text editor with the proper settings
(and 8-column indentation is too much for my taste).

Just use space characters; they don't take up enough room to be
worth worrying about.

Besides which you will normally find that a source file using
blanks and not tabs compresses better than the version with tabs.
The tabs don't even reduce the storage or transmission time needed!

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[Arthur J. O'Dwyer]

On Wed, 12 Jan 2005, Richard Bos wrote:

Mark L Pappin <ml*@acm.org> wrote:

rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:

Note that K&R was _not_ professionally typeset:
TeX gets [extra space between sentences] wrong.

You seem to be implying some causal relationship between these two
statements. My copy of K&R2 says "pic|tbl|eqn|troff-ms". No TeX
there.

No, I was simply misremembering. What I meant to say was that troff gets
this wrong. (I'll check Knuth this evening to see what TeX does).

Adds some extra space, but not (by default) a full space's worth.
Unless 'frenchspacing' is on, in which case it doesn't. See pp. 72--77
in the TeXbook.
In other words, IMHO Chris Croughton gets closest to the right answer
--- true, it's not typical to put /two/ spaces after a period, but it is
atypical to put only /one/ "space's worth" of whitespace. :)

Way OT,
-Arthur

[Micah Cowan]

Chris Croughton wrote:

On Tue, 11 Jan 2005 16:04:29 GMT, Richard Bos
<rl*@hoekstra-uitgeverij.nl> wrote:

Chris Croughton <ch***@keristor.net> wrote:

<E.**************@jpl.nasa.gov> wrote:
The question mark, colon, comma and semicolon
are English punctuation marks first.

So is dot (period, full stop). If I were writing C programs using
English punctuation rules I would write:

x = a. b? fred. bill + joe: foo. bar;

(it is conventional typography to put two spaces after a terminator,

Not anywhere else but in the USA, it isn't;

In the UK it has been for the last 40 or so years, unless they've
changed it recently (of course, almost all typesetting is done in
proportional fonts now so it isn't obvious). It was certainly that way
for dissertations when I took my degree (University of Kent at
Canterbury, UK, 1978).

and even then, not in professional typesetting. Note that K&R was
_not_ professionally typeset: TeX gets this wrong.

In professional typesetting, the post-terminator gap was still greater
than the inter-word one (how much greater depends on the typesetters).
But it was usually proportionally spaced, and so less noticable.

Chris C

"In the nineteenth century, which was a dark and inflationary
age in typography and type design, many compositors were
encouraged to stuff extra space between sentences. Generations
of twentieth-century typists were then taught to do the same,
by hitting the spacebar twice after every period. Your typing
as well as your typesetting will benefit from unlearning this
quaint Victorian habit."
-- Richard Bringhurst, "The Elements of Typographic Style"

It still seems to be a common enough practice, and I was taught
this way. Donald Knuth's typesetting program, TeX, does this by
default (as you [Chris] point out), including a command named
"\frenchspacing" to use only a single space.

Of course, Mr Bringhurst is Canadian, so perhaps this is his
belief merely because he favors French ideals over others. And I
do not claim to accept everything that Mr Bringhurst asserts in
the book quoted above. However, my own eye prefers the single
space, so this is how I set text. Not to mention the extra care I
must otherwise take to notify my typesetting S/W whenever I meant
a period to indicate abbreviation rather than sentence termination.

It is neither wrong nor right, typographically speaking, to use
extra space after a sentence terminator, since you will find
supporters on either side. It thus becomes a matter of style, and
not correctness.

It's interesting to note, though, that certain modern
technologies, such as HTML, make it somewhat difficult to specify
that extra space should be inserted in the matter we are
describing. Of course, HTML is not a particularly friendly
technology to good typography in general, regardless.

Disclaimer: I am an amateur typographer (though most of us are);
moreover, I have not typeset anything of note, and certainly
nothing that has been printed, so this must be taken as the
opinion of a mere hobbyist interested in the art of setting type.

[Lawrence Kirby]

On Mon, 10 Jan 2005 20:03:57 +0000, Chris Croughton wrote:

On Mon, 10 Jan 2005 18:32:57 +0000, Lawrence Kirby
<lk****@netactive.co.uk> wrote:

On Tue, 04 Jan 2005 22:34:49 +0000, Chris Croughton wrote:

I've tried to write a precedence-based parser for C expressions. It's
all fine apart from the ternary operator, as far as I could determine
nothing makes that come out right (I tried all combinations of left and
right precedence, and none gave the right answer for a ? b ? c : d : e).

Odd. There's no ambiguity here, there's only one possible way to parse it
so precedence is not relevant. In that respect it is similar to a[b[c]]

OK, so what (numeric or relational) precedence do you give ? and : on
the left and right?

? and : form part of the syntax of a single operator, just as [ and ] do.
They don't have separate precedence and associativity, only the operator
as a whole does. The ? : operator has the form

<expression1> ? <expression2> : <expression3>.

Precedence and associativity essentially answer the question: if an
operand could be bound to an operator on is left or one on its right which
one should we choose? The Prec/Assoc answer is to choose the one with
higher precedence or if equal choose left or right as specified by the
associativity. The important thing here is that there must be separate
operators on the left and the right for this to be relevant.

In the case of ?: there may be an operator to the left of expression1, e.g.

a + b ? c : d

Here there is the possibility of binding b either left to + forming
(a + b) ? c : d or right to ?: forming a + (b ? c : d). Since + has higher
precedence for first possibility is the one chosen. There may be an
operator to the right of expression3, e.g.

a ? b : c / d

Here / has higher precedence so the parse is as a ? b : (c / d) and not
(a ? b : c) / d. With expression2 such a possibility doesn't exist because
there aren't different operators to the left and to the right. The only
way to create a valid parse is to evaluate expression2 as a unit and use
the result for the ?: operator. So

a ? b , c : d

is parsed as a ? (b , c) : d . Even though , has lower precedence than ?:
there is no way to generate a valid parse with the ?: performed first.

Which was annoying since I did not want to use a top-down BNF parser for
it. I eventually 'solved' it with a hack which did special things with
the ternary operator...

The conditional operator IS right associative in the sense that
a ? b : c ? d : e is parsed as a ? b : (c ? d : e) and
not (a ? b : c) ? d : e

But my example was a ? b ? c : d : e. The problem is that although
visually (or with a top-down parser) it is not ambiguous, with a
bottom-up parser based on numerical precedence it doesn't (as far as I
could tell) produce the right answer in all circumstances. It generates
oddities like (a ? (b ? c) : (d : e)).

Then the parser isn't treating ?: properly as a single operator. It
appears to be treating ? and : as separate binary operators which is
wrong. How does it treat a[b[c]]?

Lawrence

[Richard Bos]

Chris Croughton <ch***@keristor.net> wrote:

On Tue, 11 Jan 2005 16:04:29 GMT, Richard Bos
<rl*@hoekstra-uitgeverij.nl> wrote:

Chris Croughton <ch***@keristor.net> wrote:

<E.**************@jpl.nasa.gov> wrote:

> The question mark, colon, comma and semicolon
> are English punctuation marks first.

So is dot (period, full stop). If I were writing C programs using
English punctuation rules I would write:

x = a. b? fred. bill + joe: foo. bar;

(it is conventional typography to put two spaces after a terminator,
Not anywhere else but in the USA, it isn't;

In the UK it has been for the last 40 or so years, unless they've
changed it recently (of course, almost all typesetting is done in
proportional fonts now so it isn't obvious).

Almost all typesetting has always been done in proportional fonts. Note
that type_writing_ is vastly different from type_setting_.
Checking a sample of books from both the UK and the USA on my shelves at
home, ISTM that only the two books I mentioned before clearly have
double spaces. All others have either a single, normal-sized space, or,
in one or two cases out of a good dozen, no more than a point or so more
than a normal space. What did show in a few of them (Penguin in
particular) is that space-capital combinations seem not to have been
kerned. This means that " W" and " T", both very common, appear loose,
while sequences like " B", quite uncommon, clearly show that the actual
size of the space is no more than normal.
It was certainly that way for dissertations when I took my degree
(University of Kent at Canterbury, UK, 1978).

Dissertations are different. For starters, they are (or at least were)
often typewritten and replicated using other methods than normal
printing, nor typeset and put on a press. With the print run of a normal
dissertation, this is probably more cost-efficient.

and even then, not in professional typesetting. Note that K&R was
_not_ professionally typeset: TeX gets this wrong.

In professional typesetting, the post-terminator gap was still greater
than the inter-word one (how much greater depends on the typesetters).
But it was usually proportionally spaced, and so less noticable.

Odd, then, that I work for a publisher, and none of the systems we use
for typesetting have separate inter-word and post-full-stop spaces, or
even a facility to enlarge the latter by a percentage.

Richard

[Richard Bos]

infobahn <in******@btinternet.com> wrote:

The whole point of the two spaces was an attempt to get around the
inflexibility of fixed-pitch fonts. In the days before proportional
fonts existed (which, from my perspective, would have been 1990 or
before, although of course other people here will undoubtedly have
encountered them much earlier than that),

Yeah. In 1440 or so :-)

Richard

[infobahn]

Richard Bos wrote:

infobahn <in******@btinternet.com> wrote:

The whole point of the two spaces was an attempt to get around the
inflexibility of fixed-pitch fonts. In the days before proportional
fonts existed (which, from my perspective, would have been 1990 or
before, although of course other people here will undoubtedly have
encountered them much earlier than that),

Yeah. In 1440 or so :-)

Touche'. :-)

Of course, I should have said something like "the days before
typical desktop computers could deal properly with proportional
fonts", which gains accuracy at the expense of brevity.

[Michael Wojcik]

In article <41**************@news.individual.net>, rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:

Chris Croughton <ch***@keristor.net> wrote:

On Tue, 11 Jan 2005 16:04:29 GMT, Richard Bos
<rl*@hoekstra-uitgeverij.nl> wrote:

Chris Croughton <ch***@keristor.net> wrote:
> <E.**************@jpl.nasa.gov> wrote:
Checking a sample of books from both the UK and the USA on my shelves at
home, ISTM that only the two books I mentioned before clearly have
double spaces. All others have either a single, normal-sized space, or,
in one or two cases out of a good dozen, no more than a point or so more
than a normal space. What did show in a few of them (Penguin in
particular) is that space-capital combinations seem not to have been
kerned.

Interesting. I'd never noticed that, but I just compared some
Penguin editions with a few books from other printers and found the
same thing. Space-capital combinations weren't kerned within
sentences either (not surprising), so that for example the name "J.
G. Something" in one of my Penguin books had excessive spacing
between the initials.
It was certainly that way for dissertations when I took my degree
(University of Kent at Canterbury, UK, 1978).

Dissertations are different. For starters, they are (or at least were)
often typewritten and replicated using other methods than normal
printing, nor typeset and put on a press. With the print run of a normal
dissertation, this is probably more cost-efficient.

My dissertation, for Miami University, will follow the new rules Ohio
has established for its state universities: deposited as a PDF
document, single-spaced. Before these new rules, they were deposited
as printed (typewritten) documents and microfilmed.

The new rules mean that dissertations written at Ohio state univer-
sities will be available almost immediately and at little cost.

I'm writing mine in LyX, so the PDF is being generated by LaTeX and
a converter, which means it'll have whatever issues TeX has; but it
still looks far, far better than anything I've seen from, say, MS
Word.

--
Michael Wojcik mi************@microfocus.com

Please enjoy the stereo action fully that will surprise you. -- Pizzicato Five

[Arthur J. O'Dwyer]

On Mon, 3 Jan 2005, Richard Bos wrote:

"Stephen Sprunk" <st*****@sprunk.org> wrote:

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote...

Albert van der Horst wrote:
Natt Serrasalmus wrote:

> a = (b == c) ? d : e;

a = b==c ? d : e;

a = (b == c)? d: e;

[...] However, aren't ? and : parts of a ternary _operator_, not _terminators_?

Yes, but their use in natural language makes a? b: c more comfortable to
me than a ? b : c.

I used to use 'a ? b : c', several years ago, but then switched to using
'a? b: c'. I don't care too much about making code /look/ like English,
but I do find that the two conventions have different connotations to me.

a ? b : c

seems to give equal "priority" to all three subexpressions. So if 'a'
were about as complicated as 'b' and 'c', and were equally likely to be
zero as non-zero, I might consider it reasonable to use that convention.
"Compute a, and then do either b or c depending on its value."

a? b: c

This convention, I read much more as an algorithm: "Is a? Then do b.
(Otherwise, do c.)" Running the '?' into the condition seems to
"minimize" its visual impact, and the asymmetry of the b--c relation
is visually emphasized.

So I tend to use the latter form these days, but I wouldn't find the
other style distracting in well-written code. This situation is to be
contrasted with the

if( a ) {
[...]
}

style, which I find annoying and distracting no matter how well-written
the rest of the code is!

-Arthur

[Chris Croughton]

On Fri, 14 Jan 2005 14:32:54 -0500 (EST), Arthur J. O'Dwyer
<aj*@nospam.andrew.cmu.edu> wrote:

a? b: c

This convention, I read much more as an algorithm: "Is a? Then do b.
(Otherwise, do c.)" Running the '?' into the condition seems to
"minimize" its visual impact, and the asymmetry of the b--c relation
is visually emphasized.
I read it all (but prefer spaces round operators) as "a implies b
otherwise c" (since they are expressions saying "do a" is not logical to
me, the verb should be 'evaluate' if anything). As far as I'm concerned
they shouldn't be too complex anyway, if the expression won't convert
fairly easily into English then it's probably better split up, possibly
as an if statement.
So I tend to use the latter form these days, but I wouldn't find the
other style distracting in well-written code. This situation is to be
contrasted with the

if( a ) {
[...]
}

style, which I find annoying and distracting no matter how well-written
the rest of the code is!

I agree, both the extra space and the open parenthesis on the if. The {
on the same line doesn't help either...

Chris C

[Mabden]

"Mark McIntyre" <ma**********@spamcop.net> wrote in message
news:vt********************************@4ax.com...

On 26 Dec 2004 14:23:43 EST, in comp.lang.c , "Natt Serrasalmus"
<Ns**********@characoid.com> wrote:

First I want to mention that I have read all the responses in this thread, Ijust don't have time to respond to them all. Thanks to those who have
replied. More below:
Natt, a word of advce. E Robert Tisdale is well-known round here for

being a very inaccurate and misleading poster. Treat his advice with caution.
And don't take my word for this

Tisdale is a C guru and all his posts are correct and should be followed
by all C coders.

--
Mabden

[Mabden]

"CBFalconer" <cb********@yahoo.com> wrote in message
news:41***************@yahoo.com...

Keith Thompson wrote:

[snip]

If you set tab stops to something other than 8 columns, the result
will be a text file that can't be viewed properly without filtering
it through "expand" or using a text editor with the proper settings
(and 8-column indentation is too much for my taste).

Just use space characters; they don't take up enough room to be
worth worrying about.

Besides which you will normally find that a source file using
blanks and not tabs compresses better than the version with tabs.
The tabs don't even reduce the storage or transmission time needed!

Uuuuhhh.... I like spaces. But I don't like your chosen indent style.
You use x and I like y. What do I do?

ie: you use 4 spaces to indent, but I like 3. We both use spaces - how
do I switch yours to mine and still have the VCS ignore them...? (OK,
some allow "ignore whitespace" but the consultant refuses to load tools
we own, or buy it)

I have an old set of DOS utilities that will tabify and untabify spaces,
but that seem harsh in our "new and improved GUI world".

Is there a "GOOD" pretty printer that "does it all" for cheap, that are
flexible to my quirks?

--
Mabden

p.s. I decided to crosspost this to c++ newsgroup, no followups.

[Mike Wahler]

"Mabden" <mabden@sbc_global.net> wrote in message
news:G0*******************@newssvr13.news.prodigy. com...

ie: you use 4 spaces to indent, but I like 3. We both use spaces - how
do I switch yours to mine and still have the VCS ignore them...? (OK,
some allow "ignore whitespace" but the consultant refuses to load tools
we own, or buy it)

Eh? The solution to a consultant who refuses to do
something is rather obvious. :-)

-Mike

[Albert van der Horst]

In article <41***************@btinternet.com>,
infobahn <in******@btinternet.com> wrote:

So I use K&R as my day-to-day reference. It's unlikely to betray
me except in odd corners of the language which I'm unlikely to use
anyway. And yes, p53 is well-worn. Of course, I don't need that
information when I *write* code; only when I read it.
I glued the table on cardboard, covered it with transparent plastic
and trimmed the corners. It has withstood the years well.
It is page 49 on my copy.
Are you talking about K&R 2, by any chance?

The use to which the Standard appears to be most commonly put is
a stick to beat people with; this is a great shame.

Well, I needed it once to convince people that the result of
a comparison is 1 not -1. Normally this doesn't matter much,
but they had

#define TRUE -1

in a header file.

--
--
Albert van der Horst,Oranjestr 8,3511 RA UTRECHT,THE NETHERLANDS
One man-hour to invent,
One man-week to implement,
One lawyer-year to patent.

[Keith Thompson]

Albert van der Horst <al****@spenarnc.xs4all.nl> writes:

In article <41***************@btinternet.com>,
infobahn <in******@btinternet.com> wrote:

[...]

The use to which the Standard appears to be most commonly put is
a stick to beat people with; this is a great shame.

Well, I needed it once to convince people that the result of
a comparison is 1 not -1. Normally this doesn't matter much,
but they had

#define TRUE -1

in a header file.

That's a silly definition, but it shouldn't break anything *if* it's
used properly. For example, something like this:

int condition = TRUE;
if (condition) ...

is ok. Something like this:

int condition = (x==y);
if (condition == TRUE) ...

will break, but this:

if (isdigit(c) == TRUE) ...

is broken for *any* possible definition of TRUE. (It might happen to
work sometimes, which just makes it worse.)

The comparison operators always yield 0 for false and 1 for true, but
any non-zero value is treated as true in a condition.

If the result of an expression is a condition (logically a boolean
value), use it as a condition; don't try to compare it for equality to
another condition.

On the other hand, anyone who would define TRUE as (-1) probably
doesn't know enough about C conditions to use it properly.

See also section 9 of the C FAQ, particularly 9.2.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[infobahn]

Mabden wrote:

"Mark McIntyre" <ma**********@spamcop.net> wrote in message
news:vt********************************@4ax.com...

Natt, a word of advce. E Robert Tisdale is well-known round here for

being

a very inaccurate and misleading poster. Treat his advice with

caution.

And don't take my word for this

Tisdale is a C guru and all his posts are correct and should be followed
by all C coders.

And God has asked everybody to send me ten major units (dollars,
pounds, euros, whatever) of their country's currrency. If we're
going for gullible, let's do it right.

[Chris Croughton]

On Fri, 18 Feb 2005 05:22:43 +0000 (UTC), infobahn
<in******@btinternet.com> wrote:

And God has asked everybody to send me ten major units (dollars,
pounds, euros, whatever) of their country's currrency. If we're
going for gullible, let's do it right.

Please be prepared to receive 80 triangular rubber coins each 6800 miles
on each side. Sorry, the banks wouldn't exchange then for 10 Triganuc
Pu because they won't take "small change"...

(Did you know that 'gullible' isn't in the dictionary?)

Chris C

[Mabden]

"Chris Croughton" <ch***@keristor.net> wrote in message
news:sl******************@ccserver.keris.net...

On Fri, 18 Feb 2005 05:22:43 +0000 (UTC), infobahn
<in******@btinternet.com> wrote:

And God has asked everybody to send me ten major units (dollars,
pounds, euros, whatever) of their country's currrency. If we're
going for gullible, let's do it right.
Please be prepared to receive 80 triangular rubber coins each 6800

miles on each side. Sorry, the banks wouldn't exchange then for 10 Triganuc
Pu because they won't take "small change"...

(Did you know that 'gullible' isn't in the dictionary?)

Obviously, you can never have the accuracy of a Tisdale, Fount of
Wisdom, and Prophet of the true C way.

--
Mabden

[Thomas Stegen]

infobahn wrote:

Mabden wrote:

And don't take my word for this

Tisdale is a C guru and all his posts are correct and should be followed
by all C coders.

And God has asked everybody to send me ten major units (dollars,
pounds, euros, whatever) of their country's currrency. If we're
going for gullible, let's do it right.

The problem with this guy is not that he is trolling, it is that
he is doing it so badly.

--
Thomas.

[Thomas Stegen]

Chris Croughton wrote:

(Did you know that 'gullible' isn't in the dictionary?)

(Did you know that 'gullible' is in the dictionary?)

http://dictionary.reference.com/search?q=gullible

Please don't ask me to define "the dictionary". I won't ask
you either :)

--
Thomas.

[Chris Croughton]

On Fri, 18 Feb 2005 14:34:36 +0000, Thomas Stegen
<th***********@gmail.com> wrote:

Chris Croughton wrote:

(Did you know that 'gullible' isn't in the dictionary?)
(Did you know that 'gullible' is in the dictionary?)

http://dictionary.reference.com/search?q=gullible

Heh, you looked it up! Of course it's in any decent dictionary of the
English language, but it's amazing how many people are gullible enough
to believe that it could be missing and go and look it up. That's the
point, it's an illustration of the word.
Please don't ask me to define "the dictionary". I won't ask
you either :)

It isn't in my Latin dictionary, or my German one (and probably isn't in
the Russian one, although I haven't checked). Overall, there are
probably more dictionaries without it than with it (more as in different
kinds, rather than in numbers published)...

Chris C

[CBFalconer]

Chris Croughton wrote:

<in******@btinternet.com> wrote:

And God has asked everybody to send me ten major units (dollars,
pounds, euros, whatever) of their country's currrency. If we're
going for gullible, let's do it right.

.... snip ...
(Did you know that 'gullible' isn't in the dictionary?)

Says something about the QUI of your dictionary. Does the name
"Schlidt" appear in the credits?

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson

[Thomas Stegen]

Chris Croughton wrote:

Heh, you looked it up! Of course it's in any decent dictionary of the
English language, but it's amazing how many people are gullible enough
to believe that it could be missing and go and look it up. That's the
point, it's an illustration of the word.

I have a feeling you have a point to make here...

:)

--
Thomas, blames it on too much tea.

[Chris Torek]

In article <sl******************@ccserver.keris.net>
Chris Croughton <ch***@keristor.net> wrote:

(Did you know that 'gullible' isn't in the dictionary?)

In fact, mine is missing everything from 'frangible' through
'hammerwort'.

:-)

[RIP DNA]
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[infobahn]

Chris Torek wrote:

In article <sl******************@ccserver.keris.net>
Chris Croughton <ch***@keristor.net> wrote:

(Did you know that 'gullible' isn't in the dictionary?)
In fact, mine is missing everything from 'frangible' through
'hammerwort'.

:-)

My dictionary jumps straight from p1018 (last complete entry: "manly")
to p1027 (first complete entry: "Marsilea").

Mao's mantra missing.

And no maps.
[RIP DNA]

And such an ironic end, too.

[Chris Croughton]

On Fri, 18 Feb 2005 21:10:59 GMT, CBFalconer
<cb********@yahoo.com> wrote:

Chris Croughton wrote:

<in******@btinternet.com> wrote:

And God has asked everybody to send me ten major units (dollars,
pounds, euros, whatever) of their country's currrency. If we're
going for gullible, let's do it right.

... snip ...

(Did you know that 'gullible' isn't in the dictionary?)

Says something about the QUI of your dictionary. Does the name
"Schlidt" appear in the credits?

No, but similar names could well have done since I was looking in a
German dictionary (and a Latin one, it wasn't in there either) <g>.

Hmm, 'gullible' doesn't appear in the C99 standard either...

Chris C

[Keith Thompson]

Chris Croughton <ch***@keristor.net> writes:
[...]

(Did you know that 'gullible' isn't in the dictionary?)

It only takes a single call to strstr() to demonstrate that "gullible"
doesn't appear in "the dictionary".

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Chris Croughton]

On Sat, 19 Feb 2005 17:38:30 GMT, Keith Thompson
<ks***@mib.org> wrote:

Chris Croughton <ch***@keristor.net> writes:
[...]

(Did you know that 'gullible' isn't in the dictionary?)

It only takes a single call to strstr() to demonstrate that "gullible"
doesn't appear in "the dictionary".

On your implementation. But I used 'gullible', which as a character
constant with more than one character is undefined behaviour <g>...

Chris C

[Mabden]

"Chris Croughton" <ch***@keristor.net> wrote in message
news:sl******************@ccserver.keris.net...

On Sat, 19 Feb 2005 17:38:30 GMT, Keith Thompson
<ks***@mib.org> wrote:

Chris Croughton <ch***@keristor.net> writes:
[...]

(Did you know that 'gullible' isn't in the dictionary?)

It only takes a single call to strstr() to demonstrate that "gullible" doesn't appear in "the dictionary".

On your implementation. But I used 'gullible', which as a character
constant with more than one character is undefined behaviour <g>...

Nevertheless, 'gullible' does appear in Chris Croughton, and Cbfalconer,
I'll bet.

--
Mabden