🚀 go-pugleaf

[Note newsgroups.  Please restrict crossposted followups to those relevant
 to both groups. -sbs]

[For the new crowd; I have been attempting to debate whether or not:
 1.  "C" and "ANSI C" are significantly different things, in particular,
  whether or not portability to pre-ANSI compilers is a desirable feature.

 2.  Whether or not code which looks like
>static char ok[256] = {
> 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 ,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
>,0,7,0,7,7,7,7,7,0,0,7,7,7,7,7,7 ,7,7,7,7,7,7,7,7,7,7,0,0,0,7,0,7
>,0,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7 ,7,7,7,7,7,7,7,7,7,7,7,0,0,0,7,7
>,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7 ,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,0
>,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 ,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
>,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 ,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
>,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 ,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
>,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 ,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
>} ;
>
>for (i = 0;s[i];++i) if (ok[(unsigned int) (unsigned char) s[i]]) return 1;
  is good style.

 3.  Whether or not declaring main to return void is, as I claim, gratuitously
  stupid and entirely benefit free.

 I apologize in advance for any resulting flames; I have come to the
 conclusion that Dan B. does not consider me a reliable and experienced
 source, and humbly offer the debate to the eyes of those wiser and more
 experienced to discuss. -s]

In article <1996Mar319.58.13.6548@koobera.math.uic.edu>,
D. J. Bernstein <djb@koobera.math.uic.edu> wrote:
>Peter Seebach <seebs@solutions.solon.com> wrote:
>> I have no problem with a program called a "compiler for a language similar
>> to C" which does not compile C.

>pcc is a C compiler.

No, it isn't.  It compiles a language which is different from the language
documented in ISO 9899-1990.  You might as well claim a yardstick is
a meter long, because it's pretty close, and would have been accepted
by most people in the absence of a standard.

>That didn't change when ANSI C was published.

Yes, it did.  In the absence of a standard, a good approximation is good
enough.  In the presence of a standard, it isn't.  For thousands of
years, anything within a certain range was "a cubit" or "a foot".  A foot
is now quite precisely defined.  You can say something is "about a foot
long" or "about a meter long", but to say it is *exactly* a foot long
requires that it adhere to the standard.  It didn't before there was
a standard.

>Of course, pcc is not an ANSI C compiler, but if you persist in equating
>``C'' with ``ANSI C'' you will continue making false statements.

C is now ANSI/ISO C.  There are related languages, including many ancestors.
Should we count BCPL as a kind of C, too?  Or B?  After all, both have
a claim to being basically the same language.

>> > > Bad style.  Magic numbers should *never* be used.  Period.
>> > More religious fanaticism. Wonderful.
>> Care to offer an example of any case in which a magic number is good
>> coding style?

>The canonical example of magic numbers is the table of constants in a
>CRC algorithm. Another example is Terje Mathisen's f_magic, i_magic
>pair. Calling this ``bad style,'' and saying that it should ``*never* be
>used,'' reflects poorly on your experience.

Those are a different kind of magic numbers.  Using an arbitrary value to
contrast with 0 in a table is bad style.  Using a specific set of numbers
because *those particular numbers work differently* is quite different.
In case you hadn't noticed, English is heavily overloaded in the area
of jargon.  Look it up; I'm talking magic number [1] in jargon - you're
then using magic number [2] and claiming it's bad style.

(Technically, yours doesn't even have the benefits of magic number [1],
namely, it *doesn't* matter that you used 7 instead of 1 as the "non-zero
value" for an if clause; this is arguably worse style, but certainly
no better.)

>Another very useful example is the 50462976 trick---

>   static uint32 tr[4] = { 50462976, 117835012, 185207048, 252579084 } ;
>   #define ctr ((unsigned char *) tr)

>---where I think being flashy for the novice reader is much more fun
>than writing the constants in the most obvious way. (I'd _love_ to see
>your ``portable'' version of this code, btw.)

Well, to start with, I wouldn't have used a byte-order dependant form.
I'd probably do
	static unsigned char ctr[16] = {
		0x00, 0x01, 0x02, 0x03,
		0x04, 0x05, 0x06, 0x06,
		0x08, 0x09, 0x0A, 0x0B,
		0x0C, 0x0D, 0x0E, 0x0F,
	};
and my code would work similarly, except that someone unfamiliar with
the code could tell exactly what I meant it to do.  Additionally, my
code would work on machines of arbitrary byte order or byte size.

>> Fascinating; how, precisely, is it not a magic number?

>Easy: there's nothing magic about it. Any other number (except multiples
>of 256) would have the same effect.

Well, in that case, we're back to the old style point of not putting in
extra information that has no meaning.  One traditionally favors 0 for
false and 1 for true, *when producing values*.  (Only fools do things
like
	if (isalpha(c) == 1)
...)

If you produce other values, or use them, it is implicit that there's a reason
for it; if this reason is undocumented, you have introduced a magic number
[1].  If there is no reason, you have wasted a future maintainer's time.

>Very good. Now you understand why I only gave you _part_ of the test: I
>wanted you to focus on what was happening inside the code, without being
>distracted by its purpose.

Focussing on what is happening, without looking at the purpose, is a good
way to discover a microoptimization that lets a redundant or useless test
occur in 20% less time.

>> The poor sod has to search for references to the table
>> and scrounge around trying to figure out what meaning, if any, the 7 had.

>The production version of that code is a dinky little (77-line) quote.c,
>where the ``ok'' table is declared static and used exactly once. Not too
>hard to figure out.

Except that even then, they have to study the usage to determine that,
apparently, it's just "non-zero" that's relevant.  If you use 0's and 1's,
it is obvious to any reader instantly what you plan to do; if you use
0's and 7's, you are indicating that something is probably up.

[re: void main]

>> Okay; how about this.  No *significant* benefit.  And a significant
>> loss.

>Depends on what's ``significant'' to the programmer. Anyway, I take it
>you're no longer claiming ``NO BENEFIT WHATSOEVER''?

I still maintain that there is no *benefit*.  You may find it convenient
or pleasureable to declare main to return void; so?  Rats will self-administer
pleasure center shocks until they starve.  For it to be a benefit, it must
provide an enhancement to the code.  The illusion of being able to fall
off the end of main without consequences is hardly a benefit.

[re: the "mistakes" I make in ignoring pre-ANSI bogosities, like the redundant
 cast to (unsigned int) in the example code above.]
>> I am *by definition* not making mistakes.

>Good .sig fodder.

It certainly is.  Other ones you may find relevant:
	"This is (no offense meant) just plain stupid."

-s
-- 
Peter Seebach - seebs@solon.com - Copyright 1996 Peter Seebach.
C/Unix wizard -- C/Unix questions? Send mail for help.  No, really!
FUCK the communications decency act.  Goddamned government.  [literally.]
The *other* C FAQ - http://www.solon.com/~seebs/c/c-iaq.html