size of a sizeof(pointer)

[Dan Pop]

machine code. I'm not familiar with the AS/400, but I haven't seen
anything to suggest that C is a poor language for it.

It depends on how you define the notion of poor language.

It is a fact that C is not the language of choice for the primary
application domain of this machine (small business server) and that very
little (if any) of the open source C code available on the Internet
has been ported to that platform (or written with portability to this
platform in mind).

It is possible to program in C on this machine, but apparently few of
those who did it actually enjoyed the experience. And this has precious
little to do with the unusual pointer size/representation.

Dan

 

[Michael Wojcik]

C programmers working on the AS/400 will find that expectation
[that pointer dereferences compile to single machine instructions ] is
incorrect. In C on the AS/400, *nothing* compiles to machine
instructions, single or otherwise. It compiles to a pseudoassembly
language called "MI".

This really is the exception that proves the point.

That's not what that idiom means. "The exception proves the rule"
is a partial vernacular translation of a Latin legal principle which
means that when an exception is explicit in the law ("No parking
between 9AM and 5PM"), it implies a general rule where the exception
does not apply ("You may park between 5PM and 9AM").

In what logical system does the existence of an exception prove that
the general thesis is true? In fact, what we have here is an
exception which disproves the thesis. See [1].

A platform that
disallows native machine langauge programs cannot really be said to have a
compiler.

Oh yes it can. Observe: There are compiled languages on the AS/400.
Perhaps you need to review what a "compiler" is. Hint: it's not a
system for translating some source language into "native machine
language". That's why Java, for example, is still a compiled
language.

A compiler *compiles*. It collects multiple source statements and
processes them as a whole into some form more amenable for execution.
Contrast that with an interpreter, which is incremental - it processes
and executes one "statement" (however defined by the language) at a
time.

In any case, the C standard says nothing about compilation. There is
an implementation, which acts upon translation units. A program is
composed of one or more translation units, which undergo the various
translation stages specified by the standard.

Nor is C the ideal language for such an environment - you need
something which does memory management for you.

Really. Care to expand upon this rather bizarre thesis? In what
way do the characteristics of the AS/400 1) make C any less "ideal"
there than on any other platform, or 2) require automatic memory
management?


1. http://alt-usage-english.org/excerpts/fxtheexc.html

 

[Michael Wojcik]

But if you believe that C on this machine is not "compiled", then
you must believe that *nothing* on the AS/400 is *ever* compiled --
not COBOL, not RPG, not Modula-2. Yet IBM will sell you "compilers"
for all of these, as well as for C and C++.

Indeed, though I suppose we shouldn't in general allow IBM to define
"compiler" for us. Still, I think the consensus among AS/400
programmers is that we are, indeed, compiling our programs, and I
defy Malcolm to prove otherwise.

There are even AS/400
assemblers that read "MI" source and produces "machine code":
<http://www-1.ibm.com/servers/eserver/iseries/whpapr/translator.html>.

In fact, there used to be (and probably still is) a C API supplied by
IBM for this purpose; IIRC, it was just a function that took a
FILE* referring to a file open for writing and a string containing
MI source, assembled the latter, and wrote it into the former. Which
made the AS/400 the easiest machine I knew of to write an assembler
for...

(MI is a nicely CISCy pseudo-assembly, with opcodes like "translate
byte using table". Not as CISCy as VAX assembly, as I recall, but
pretty rich.)

 

[Malcolm]

Would you also claim that any machine on which the machine's
"opcodes" are interpreted by microcode has no compilers? If not,
why do you distinguish between OMI opcodes and microcoded-
machine opcodes?

Let's say someone produces a tool that converts C code to compliant C++
code - e.g. alters C++ keywords used as identifiers, adds prototypes, adds
explicit casts of void * etc. Would you describe such a program as a C
compiler? If not, why not?

Microcode creates a grey area. I would say that the difference is between an
intermediate bytecode that is designed for arbitrary hardware, and a program
which is hardware-specific, although it relies on some microcode to support
that hardware. Of course a really good optimising C compiler should build
and load microcode itself .

Ultimately it's just a question of definition - how far can we extend the
term "compiler" until we're talking about two totally different things? The
AS/400 almost certainly contains a substantial amount of C code which is
compiled to native machine code and runs the OS. How are we to distiguish
this compiler from the "compiler" shipped to customers?

 

[Malcolm]

If you ever see me using sophistry like that, here,
it will be the first of April.

"The exception proves the rule" is a famous proverb. "Prove" means "tests",
not "demonstrates the point".

Now I claimed that not a single compiler, to my knowledge, implemented safe
pointers. An exception was raised. However on examination we see that the
"compiler" isn't really a compiler at all, if we define "compiler" as
"something that translates source code to machine code". So the exception
actually demonstrates that the point is valid.

 

[Chris Torek]

Let's say someone produces a tool that converts C code to compliant C++
code - e.g. alters C++ keywords used as identifiers, adds prototypes, adds
explicit casts of void * etc. Would you describe such a program as a C
compiler? If not, why not?

Generally, I *would* call it a compiler (provided it produced an
executable image in the process, perhaps by later invoking the
"assembler" that translates the C++ to machine code). But if this
particular translator depended on the C++-to-machine-code step to
find certain fundamental errors, that is a -- perhaps even the only
-- condition under which I would not call it a compiler.

I am not sure I can define it very well, so consider the following
as an example, before I go on to an attempt at a definition:

% cat bug.c
int main(void] { return *42; }
% ctocxx -C bug.c

(Here, please assume the -C option means "leave the C++ `assembly'
visible for inspection, and that no diagnostics occur.)

% cat bug.c++
int main(] { return *42; }
%

This fails the "compiler" criterion by missing the obvious syntax
error ("]" should be "}") and semantic error (unary "*" cannot be
applied to an integer constant). (And of course, if main() were
to call itself recursively in the C version, the C++ code would
have to use some other function, or depend on that particular C++
implementation to allow recursive calls to main() -- either would
be acceptable, provided the "C compiler" comes *with* the C++
compiler portion. If the C compiler is meant to work with *any*
C++ compiler, depending on implementation-defined characteristics
would be at best a bug.)

The difference is basically one of responsibility: to be called a
"compiler", the program must make a complete syntactic and semantic
analysis of the source code, determine its "intended meaning" (or
one of several meanings, in cases where the source language has
various freedoms), and generate as its output code that is intended
to pass cleanly through any (required and/or supplied) intermediate
stages before it produces the final "executable". If something
fails to "assemble" without the "compiler" stage first pointing out
an error, this indicates a bug in the compiler.

A preprocessor, macro-processor, or textual-substitution system, on
the other hand, does not need to make complete analyses -- if the
input is erroneous, its output can be arbitrarily malformed without
this necessarily being a bug. Diagnostics from later passes are
acceptable and expected.

Of course, escape hatches (as commonly found in C compilers with
__asm__ keywords and the like) can muddy things up a bit. If you
use __asm__ to insert invalid assembly code, while the compiler
assumes that you know what you are doing, this is probably "your
fault". Likewise, a C-via-C++-to-executable compiler might provide
an escape hatch to "raw C++", and if you muck that up, it would be
your fault, rather than a compiler bug or disqualifier.

(Note that a clever implementor might even use the C++ stage to
find [some of the] required-diagnostic bugs in incorrect C code.
I consider this "OK" and "not a disqualifier" *if* the C compiler
actually reads and digests the C++ stage's diagnostics, and re-forms
them back to refer to the original C code, so that the process is
invisible to the C programmer.)

 

[Mark McIntyre]

C programmers working on the AS/400 will find that expectation
[that pointer dereferences compile to single machine instructions ] is
incorrect. In C on the AS/400, *nothing* compiles to machine
instructions, single or otherwise. It compiles to a pseudoassembly
language called "MI".

This really is the exception that proves the point.

That's not what that idiom means. "The exception proves the rule"
is a partial vernacular translation of a Latin legal principle

possibly. Its probably more likely that the saying uses the alternate
meaning of "prove" which is "test". As in the "proof of the pudding is in
the eating".

 

[Arthur J. O'Dwyer]

Let's say someone produces a tool that converts C code to compliant C++
code - e.g. alters C++ keywords used as identifiers, adds prototypes, adds
explicit casts of void * etc. Would you describe such a program as a C
compiler? If not, why not?

I would call it a "translator" -- a translator that translates C code
to C++ code. It would definitely be an "implementation" of C in the
sense the word is used in the Standard (which is a broad term
encompassing compilers, interpreters, translators, and whatever else
an implementor can think up).

[Oh yeah, and BTW, that's a pretty neat idea. An open-source C
munger would cut down on at least *one* of the perennial flamewar
topics in this newsgroup.]

Ultimately it's just a question of definition - how far can we extend
the term "compiler" until we're talking about two totally different
things?

How far can a dog run into the woods? Just call a thing a "compiler"
unless you think it's not -- and then don't. At root, my opinion would
simply be that all compilers are translators, and not necessarily vice
versa, and that the word "compiler" has taken on a special connotation
in the minds of those who market software, to the point where they think
it's something magic involving hardware and stuff.

The AS/400 almost certainly contains a substantial amount of C code
which is compiled to native machine code and runs the OS. How are we
to distiguish this compiler from the "compiler" shipped to customers?

Why do you think we need to distinguish between them? I think
we should call a spade a spade, and if someone's not sure it *is* a
spade, then we should just call it a digging implement that looks
very much *like* a spade, and move on to more C-related topics. ;-)

-Arthur

 

[Richard Heathfield]

Generally, I *would* call it a compiler (provided it produced an
executable image in the process, perhaps by later invoking the
"assembler" that translates the C++ to machine code).

Well, it's obviously your prerogative to use words as you choose, but your
proviso here flies in the face of Aho, Sethi and Ullman's definition: "a
compiler is a program that reads a program written in one language - the
source language - and translates it to an equivalent program in another
language - the target language" - no mention there of executable images.
Source: Dragon Book (Chapter 1, page 1!)

<snip>

 

[Keith Thompson]

Ultimately it's just a question of definition - how far can we extend the
term "compiler" until we're talking about two totally different things? The
AS/400 almost certainly contains a substantial amount of C code which is
compiled to native machine code and runs the OS. How are we to distiguish
this compiler from the "compiler" shipped to customers?

You're almost certain that the AS/400 OS is written in C? You may be
right, but my guess is that it's written in some other language(s).

 

[Malcolm]

That's not what that idiom means. "The exception proves the rule"
is a partial vernacular translation of a Latin legal principle which
means that when an exception is explicit in the law ("No parking
between 9AM and 5PM"), it implies a general rule where the
exception does not apply ("You may park between 5PM and 9AM").

Etymology isn't meaning. The proverb is not used in that way. (By the way
the etymology itself is dodgy)
http://www.icsi.berkeley.edu/~nchang/personal/exception.html

In what logical system does the existence of an exception prove that
the general thesis is true? In fact, what we have here is an
exception which disproves the thesis. See [1].

It's not something in formal logic, but a rule of thumb. To see if a rule
applies, look at cases that appear to be exceptions. For instance if I say
"All mammals are viviparous" then looking at chickens, or bats, which are
not exceptions to the rule, isn't helpful. However if we look at the
duck-billed platypus and echidna, which lay eggs, we find that they are
formally mammals, but they split off from the rest of the mammals a long
time ago. The rule is still useful - we won't find an oviparous antelope.
Let's take another example, "No mammals are eusocial." Well the naked mole
rat is eusocial, and wolves are a borderline case. There is nothing much
else in common between these animals, and they are not otherwise special. We
conclude that the rule isn't too useful - there's nothing special about
being a mammal that precludes eusociality.

End of logic 101, back to C.

Oh yes it can. Observe: There are compiled languages on the
AS/400.

It depends how you want to use the word. If anyone with a little bit of
computer knowledge asked "What's a compiler?" I would say "Something that
translates a high-level language to machine code."

In any case, the C standard says nothing about compilation.

You can build a C interpreter. What's your point, that mentioning "the
compiler" makes a post off-topic?

Really. Care to expand upon this rather bizarre thesis? In what
way do the characteristics of the AS/400 1) make C any less "ideal"
there than on any other platform, or 2) require automatic memory
management?

Because C sacrifices safety in memory access for efficiency. Since the
platform won't allow this, the safety has to be put in at an inappropriate
level. So I would guess that when writing a function to iterate over a
string, the pointer is checked for out-of-bounds at every increment.
Certainly passing a pointer, if it contains validity information, will be
very slow.
If you do memory management at a higher level then you can have similar
safety, but raw pointers can be used internally (where the user code can't
mess with them).

There ceases to be a point in using C on the AS/400, except that C is a very
popular language, and there is always a point in supporting a standard. A
bit like driving a sports car over a traffic-calmed road - it can't go very
fast and a hatchback would make more sense, but if you own a sports car
already then you might want to do it.

 

[Joona I Palaste]

A compiler *compiles*. It collects multiple source statements and
processes them as a whole into some form more amenable for execution.
Contrast that with an interpreter, which is incremental - it processes
and executes one "statement" (however defined by the language) at a
time.

Could the distinction between a compiler and an interpreter be that when
they encounter program code, compilers translate it into another
language, while interpreters execute it? In other words, more or less,
compilers store away code for later execution while interpreters execute
it when they see it?

 

[nrk]

Well, it's obviously your prerogative to use words as you choose, but your
proviso here flies in the face of Aho, Sethi and Ullman's definition: "a
compiler is a program that reads a program written in one language - the
source language - and translates it to an equivalent program in another
language - the target language" - no mention there of executable images.
Source: Dragon Book (Chapter 1, page 1!)

<snip>

From "Advanced Compiler Design and Implementation" by Steven S. Muchnik:

<quote>
Strictly speaking, compilers are software systems that translate programs
written in higher-level languages into equivalent programs in object code
or machine language for execution on a computer.
....
The definition can be widened to include systems that translate from one
higher-level language to an indermediate-level form, etc.
</quote>

One might argue that an author/book cannot serve as an authoritative
definition of a term, but considering the widespread use and popularity of
the book, I would tend to take this to be an appropriate definition.

-nrk.

 

[Les Cargill]

From "Advanced Compiler Design and Implementation" by Steven S. Muchnik:

<quote>
Strictly speaking, compilers are software systems that translate programs
written in higher-level languages into equivalent programs in object code
or machine language for execution on a computer.
...
The definition can be widened to include systems that translate from one
higher-level language to an indermediate-level form, etc.
</quote>

One might argue that an author/book cannot serve as an authoritative
definition of a term, but considering the widespread use and popularity of
the book, I would tend to take this to be an appropriate definition.

-nrk.

Muchnik's book's version is problematic. The Aho, Sethi and
Ullman version is
a much more disciplined definition.

Object code itself is a "language".

There may be, and usually are, several stages to producing
executables from
source code - compilation, assembly ( which is just a
specialization of
compilation ), linking, (possibly) locating and
loading/storage. That
some of thes estages are hidden behind one command or ( button
on
an IDE) is a matter of packaging, not of much else.

 

[Keith Thompson]

From "Advanced Compiler Design and Implementation" by Steven S. Muchnik:

<quote>
Strictly speaking, compilers are software systems that translate programs
written in higher-level languages into equivalent programs in object code
or machine language for execution on a computer.
...
The definition can be widened to include systems that translate from one
higher-level language to an indermediate-level form, etc.
</quote>

One might argue that an author/book cannot serve as an authoritative
definition of a term, but considering the widespread use and popularity of
the book, I would tend to take this to be an appropriate definition.

Doesn't IEEE have an official dictionary of computer terms? Can
someone who has a copy look up "compiler"?

For what it's worth, the first compiler I used (UCSD Pascal) generated
a pseudo-code (P-code) which was then interpreted; nobody ever called
it a translator rather than a compiler. (Later, one company started
making chips that executed P-code in hardware, or at least in
microcode.)

 

[Chris Torek]

(This is getting pretty far off topic and perhaps should move to
comp.programming or even the moderated group, comp.compilers...)

Well, it's obviously your prerogative to use words as you choose, but your
proviso here flies in the face of Aho, Sethi and Ullman's definition: "a
compiler is a program that reads a program written in one language - the
source language - and translates it to an equivalent program in another
language - the target language" - no mention there of executable images.
Source: Dragon Book (Chapter 1, page 1!)

As nrk points out in a followup, there is at least some disagreement
over precisely what a "compiler" is. I am happy to work with the
Dragon Book definition (which, to be honest, I had actually forgotten
-- it has, after all, been 20 years! ) as well. In this case,
a translator much like the original "cfront" is also a compiler
even if it never produces an executable.

Given that we have the word "translator", however, I personally
would tend to use that word for a system in which the "produce
something useful" step requires outside assistance, such as a
C++-to-C step that not only does not come with a C compiler, but
is provided for a computer for which no C compiler is even available.
It is probably also worth pointing out that there are a number% of
compilers that have produced C as their "assembly code", but in
all cases of which I am aware, that C code was not portable at all
-- you had to tell the XYZ-to-C step "this implementation has 32-bit
int, is big-endian, widens all floats to double, uses a stack for
variable arguments", and all sorts of other things tied to the
specific implementation. Thus, calling the C output an "equivalent
program" is perhaps stretching the truth: it is only "equivalent"
for one specific machine or group of machines, not for all systems
on which C runs.

Finally, let me note that this sort of thing is why it sometimes
pays to step back and define one's terms. People can argue forever
fruitlessly over nitpicky details, never reaching any agreement,
simply because they started with different definitions. This, in
fact, is why we have C standards: without a common definition of
what it is to "be" a C program, it may be impossible for two people
-- or even one person and a compiler -- to reach agreement as to
what the source-language program *means*.

[%footnote: when I say "a number" I do mean "more than one". While
cfront is perhaps the best-known example, I believe Xerox PARC had
C back-ends for some of their compilers, for the language that was
a followon to Mesa -- I have forgotten its name -- and for Modula-3,
for instance.]

 

[Michael Wojcik]

Let's say someone produces a tool that converts C code to compliant C++
code - e.g. alters C++ keywords used as identifiers, adds prototypes, adds
explicit casts of void * etc. Would you describe such a program as a C
compiler? If not, why not?

I posted a perfectly workable definition of "compiler" which easily
deals with this sort of case. A compiler is a software tool which
processes translation units (files, in many implementations - though
not in OS/400, for one) in their entirety (that's the "compilation"
process), converting them into a form more amenable for execution.
The compiler's output need not be directly executable by the OS - and
indeed in many cases is not - it just needs to be further along the
process.

If, for some reason, you have an implementation which supplies only
a C++ compiler, then a C-to-C++ translator would be a C compiler for
that system. It would serve to move C source translation units
further along the path to executable form.

Microcode creates a grey area.

Not if you have a sensible, consistent definition of "compiler".

I would say that the difference is between an
intermediate bytecode that is designed for arbitrary hardware, and a program
which is hardware-specific, although it relies on some microcode to support
that hardware.

The difference between what and what else?

Ultimately it's just a question of definition

Yes, that's what determines what a word, such as "compiler", means.

- how far can we extend the
term "compiler" until we're talking about two totally different things?

I'm afraid I don't see what "two totally different things" are under
discussion here. I might guess you mean, on the one hand, one of the
OS/400 C implementations, and on the other some C implementation more
familiar to you, but those strike me as two things which are not very
different at all.

The
AS/400 almost certainly contains a substantial amount of C code which is
compiled to native machine code and runs the OS.

How did you come by this information? The internals of OS/400 are for
the most part a closely guarded secret. Could it be that you are making
a wild, unsubstantiated guess?

(In point of fact, what I've heard informally from IBM insiders is that
the majority of the original OS/400 implementation was written in PL/I.
Rumor has it was substantially rewritten for the RISC implementation.
That's the LIC - Licensed Internal Code - which is the equivalent of the
kernel in OS/400 and is said to be the only part of the OS which is
native code. The bulk of the OS, including the shell and utilities, is
in theory compiled to MI. Again, this may have only been true in the
early implementations, with more pieces migrated to native code as the
OS evolved.)

How are we to distiguish
this compiler from the "compiler" shipped to customers?

Most obviously, in that it's not available to customers. And, of
course, it has a different target. What exactly is your point?

 

[Michael Wojcik]

"The exception proves the rule" is a famous proverb. "Prove" means "tests",
not "demonstrates the point".

Yes, "prove" does sometimes mean "test". However, the phrase "the
exception proves the rule" does not use "prove" in this sense. See the
link I provided in my first reply. You are victim of a folk etymology.

Now I claimed that not a single compiler, to my knowledge, implemented safe
pointers. An exception was raised.

Well, that's what safe pointers are for, after all...

However on examination we see that the
"compiler" isn't really a compiler at all, if we define "compiler" as
"something that translates source code to machine code".

And if we define "compiler" as "person who assembles documents out
of individual pages", gcc isn't a compiler either.

So the exception actually demonstrates that the point is valid.

What it demonstrated was that your claim was wrong, and your definition
of "compiler" is overly restrictive and opportunistic, introduced solely
in an attempt to save a bogus argument.


--
Michael Wojcik (e-mail address removed)

This book uses the modern technology to explain the phenomemon in the world
of Japanese animation. If you love anime so much, you'd better read this.
After you read it, you may agree that is destroying the dream of the child.
Needs Chinese viewing system. -- The Goodboy Scientific

 

[Michael Wojcik]

possibly. Its probably more likely that the saying uses the alternate
meaning of "prove" which is "test". As in the "proof of the pudding is in
the eating".

"more likely" according to whom? The consensus I've seen (in
alt.usage.english and elsewhere) appears to be that that's a folk
etymology, albeit one popular with armchair pedants. The OED agrees
with the derivation from "exceptio probat regulam...", though it
admits that the phrase is "commonly" used with "the [substantive]
being interpreted in sense 2". But even this does not imply use
of "prove" as "test": the OED's "sense 2" for "exception" is simply
"a particular case which comes under the terms of a rule, but to
which the rule is not applicable". The OED's examples of this
usage do not use "prove" for "test", but rather are all cases of
just the sort of handwaving normally seen with casual use of the
phrase - a suggestion that the existence of an exception or two
just makes the rule "stronger" or more persuasive.[1]


1. _Oxford English Dictionary_, 2nd ed. See under "exception".

 

[Michael Wojcik]

Etymology isn't meaning. The proverb is not used in that way.

It is by some of us. And I'm well aware of how language works,
thanks. I was simply hoping to point out that you were employing a
bogus argument through an unfortunately popular turn of phrase,
apparently under the misapprehension that its common misuse made it
logically valid. Now it appears that you are simply unable to
understand that it's a bogus argument.

(By the way the etymology itself is dodgy)
http://www.icsi.berkeley.edu/~nchang/personal/exception.html

Few things are crystal-clear in English etymology. The fact that
Nancy Chang happened upon one philologist who happened to think that
the phrase originally employed "prove" in the sense of "test" does
little to contradict the evaluations of more authoritive sources,
which agree with Bergen rather than Breen. And, frankly, I don't
see much validity to Breen's argument; derivation from German rather
than Latin does nothing to demonstrate that "prove" should be used
in the sense of "test".

It's not something in formal logic, but a rule of thumb.

Ah, my favorite form of argument. "It's not logical, just something
that's often kinda sorta right."

To see if a rule
applies, look at cases that appear to be exceptions.

That process falls quite nicely under logic. It's called "trying
to prove the thesis by negation of the converse". Unfortunately
for your argument, what it proves is that the converse is false.

Your examples don't demonstrate anything except the difference
between a universal rule and a general one. I fail to see how that's
germane to the argument, which is whether the various C implementa-
tions for the AS/400 are a counterexample to the thesis that "no C
implementations provide safe pointers". At least one exception
exists; the thesis is phrased as a universal rule and so is disproven.

Now, apparently, you want to convert this thesis into a general rule
("few C implementations provide safe pointers"), but since this is
an unremarkable statement, you hope to salvage its force by relegating
its exceptions to some second-class status. It's barely a step beyond
argument-by-sticking-one's-fingers-in-one's-ears.

Because C sacrifices safety in memory access for efficiency.

Chapter and verse, please. (Oh, I realize this is standard C lore.
But the language does not *depend* on this trade-off, and it has
many admirable qualities which have nothing to do with it.)

Since the
platform won't allow this, the safety has to be put in at an inappropriate
level. So I would guess that when writing a function to iterate over a
string, the pointer is checked for out-of-bounds at every increment.

Your guess would be wrong, in the general case.

Certainly passing a pointer, if it contains validity information, will be
very slow.

Pointers in the various AS/400 C implementations are 16 bytes long.
Why should passing such an object be "very slow"?

There ceases to be a point in using C on the AS/400, except that C is a very
popular language, and there is always a point in supporting a standard.

The presence of (at least) three commercial C implementations for the
AS/400, and AS/400 software developed using them, suggests that a
significant number of people disagree with this claim as well.

A
bit like driving a sports car over a traffic-calmed road - it can't go very
fast and a hatchback would make more sense, but if you own a sports car
already then you might want to do it.

So your contention is that C is a sensible language to use only on
platforms where it can be used in a dangerous mannner? Perhaps we
should take a little c.l.c poll. How many people here use C because
it lets you do unsafe things?