473,842 Members | 1,958 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Making Fatal Hidden Assumptions

We often find hidden, and totally unnecessary, assumptions being
made in code. The following leans heavily on one particular
example, which happens to be in C. However similar things can (and
do) occur in any language.

These assumptions are generally made because of familiarity with
the language. As a non-code example, consider the idea that the
faulty code is written by blackguards bent on foulling the
language. The term blackguards is not in favor these days, and for
good reason. However, the older you are, the more likely you are
to have used it since childhood, and to use it again, barring
specific thought on the subject. The same type of thing applies to
writing code.

I hope, with this little monograph, to encourage people to examine
some hidden assumptions they are making in their code. As ever, in
dealing with C, the reference standard is the ISO C standard.
Versions can be found in text and pdf format, by searching for N869
and N1124. [1] The latter does not have a text version, but is
more up-to-date.

We will always have innocent appearing code with these kinds of
assumptions built-in. However it would be wise to annotate such
code to make the assumptions explicit, which can avoid a great deal
of agony when the code is reused under other systems.

In the following example, the code is as downloaded from the
referenced URL, and the comments are entirely mine, including the
'every 5' linenumber references.

/* Making fatal hidden assumptions */
/* Paul Hsiehs version of strlen.
http://www.azillionmonkeys.com/qed/asmexample.html

Some sneaky hidden assumptions here:
1. p = s - 1 is valid. Not guaranteed. Careless coding.
2. cast (int) p is meaningful. Not guaranteed.
3. Use of 2's complement arithmetic.
4. ints have no trap representations or hidden bits.
5. 4 == sizeof(int) && 8 == CHAR_BIT.
6. size_t is actually int.
7. sizeof(int) is a power of 2.
8. int alignment depends on a zeroed bit field.

Since strlen is normally supplied by the system, the system
designer can guarantee all but item 1. Otherwise this is
not portable. Item 1 can probably be beaten by suitable
code reorganization to avoid the initial p = s - 1. This
is a serious bug which, for example, can cause segfaults
on many systems. It is most likely to foul when (int)s
has the value 0, and is meaningful.

He fails to make the valid assumption: 1 == sizeof(char).
*/

#define hasNulByte(x) ((x - 0x01010101) & ~x & 0x80808080)
#define SW (sizeof (int) / sizeof (char))

int xstrlen (const char *s) {
const char *p; /* 5 */
int d;

p = s - 1;
do {
p++; /* 10 */
if ((((int) p) & (SW - 1)) == 0) {
do {
d = *((int *) p);
p += SW;
} while (!hasNulByte (d)); /* 15 */
p -= SW;
}
} while (*p != 0);
return p - s;
} /* 20 */

Let us start with line 1! The constants appear to require that
sizeof(int) be 4, and that CHAR_BIT be precisely 8. I haven't
really looked too closely, and it is possible that the ~x term
allows for larger sizeof(int), but nothing allows for larger
CHAR_BIT. A further hidden assumption is that there are no trap
values in the representation of an int. Its functioning is
doubtful when sizeof(int) is less that 4. At the least it will
force promotion to long, which will seriously affect the speed.

This is an ingenious and speedy way of detecting a zero byte within
an int, provided the preconditions are met. There is nothing wrong
with it, PROVIDED we know when it is valid.

In line 2 we have the confusing use of sizeof(char), which is 1 by
definition. This just serves to obscure the fact that SW is
actually sizeof(int) later. No hidden assumptions have been made
here, but the usage helps to conceal later assumptions.

Line 4. Since this is intended to replace the systems strlen()
function, it would seem advantageous to use the appropriate
signature for the function. In particular strlen returns a size_t,
not an int. size_t is always unsigned.

In line 8 we come to a biggie. The standard specifically does not
guarantee the action of a pointer below an object. The only real
purpose of this statement is to compensate for the initial
increment in line 10. This can be avoided by rearrangement of the
code, which will then let the routine function where the
assumptions are valid. This is the only real error in the code
that I see.

In line 11 we have several hidden assumptions. The first is that
the cast of a pointer to an int is valid. This is never
guaranteed. A pointer can be much larger than an int, and may have
all sorts of non-integer like information embedded, such as segment
id. If sizeof(int) is less than 4 the validity of this is even
less likely.

Then we come to the purpose of the statement, which is to discover
if the pointer is suitably aligned for an int. It does this by
bit-anding with SW-1, which is the concealed sizeof(int)-1. This
won't be very useful if sizeof(int) is, say, 3 or any other
non-poweroftwo. In addition, it assumes that an aligned pointer
will have those bits zero. While this last is very likely in
todays systems, it is still an assumption. The system designer is
entitled to assume this, but user code is not.

Line 13 again uses the unwarranted cast of a pointer to an int.
This enables the use of the already suspicious macro hasNulByte in
line 15.

If all these assumptions are correct, line 19 finally calculates a
pointer difference (which is valid, and of type size_t or ssize_t,
but will always fit into a size_t). It then does a concealed cast
of this into an int, which could cause undefined or implementation
defined behaviour if the value exceeds what will fit into an int.
This one is also unnecessary, since it is trivial to define the
return type as size_t and guarantee success.

I haven't even mentioned the assumption of 2's complement
arithmetic, which I believe to be embedded in the hasNulByte
macro. I haven't bothered to think this out.

Would you believe that so many hidden assumptions can be embedded
in such innocent looking code? The sneaky thing is that the code
appears trivially correct at first glance. This is the stuff that
Heisenbugs are made of. Yet use of such code is fairly safe if we
are aware of those hidden assumptions.

I have cross-posted this without setting follow-ups, because I
believe that discussion will be valid in all the newsgroups posted.

[1] The draft C standards can be found at:
<http://www.open-std.org/jtc1/sc22/wg14/www/docs/>

--
"If you want to post a followup via groups.google.c om, 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
More details at: <http://cfaj.freeshell. org/google/>
Also see <http://www.safalra.com/special/googlegroupsrep ly/>

Mar 6 '06
351 13203
"Ed Prochak" <ed*******@gmai l.com> writes:
Keith Thompson wrote:
"Ed Prochak" <ed*******@gmai l.com> writes:
> Keith Thompson wrote:
>> "Ed Prochak" <ed*******@gmai l.com> writes:
>> [...]
>> > C is an assembler because
>
> I should have phrased this: C is LIKE an assembler.
And a raven is like a writing desk.
<http://www.straightdop e.com/classics/a5_266.html>

"C is an assembler" and "C is like an assembler" are two *very*
different statements. The latter is obviously true, given a
sufficiently loose interpretation of "like".


Well my original statement was that C was a glorified assembler.
We don't need to stretch the meaning of like to the breaking point.


And my assertion is that C is not an assembler, glorified or
otherwise. I doubt that we're going to come to an agreement on that
point.

[...] The point is I can assign an integer value to a pointer. The warning
is a nice reminder, but that is all it is. Assemblers allow integers
to be used as pointers. Many HLL's never allow this. Can you suggest
another HLL that allows simple assignment of integer to pointer? (I
recall PL/M, a version of PL/1 for micros from INTEL. It specifically
for embedded programming so this was a required feature.)
C (as defined by the current standards) does not allow simple
assignment of an integer to a pointer. It specifically states that
doing so is a constraint violation. It's just as strongly prohibited
as assigning a structure to a floating-point object, or using "<" to
compare a union and a pointer.

The only thing that a compiler is actually required to reject is a
translation unit containing a "#error" directive.

The fact that some compilers choose to deal with this particular
constraint violation by issuing a warning and accepting the
translation unit is an attribute of those compilers, not of the
language.

C does allow conversion between pointers and integers, and that's a
relatively low-level feature. But any language intended for
system-level programming (operating system, embedded, whatever) is
going to have some mechanism for doing machine-level operations. I
used Ada as an example because I'm very familiar with it, but I'm sure
other languages have similar features. Pascal in its purest form
doesn't because it was designed as a teaching language -- but I expect
that any Pascal dialect that's actually used in the real world allows
low-level operations.

[snip]
You are missing my point. It has nothing to do with whether C generates
a diagnostic. And I'll happily accept the cast to be rid of it. Point
is I can manipulate memory pointers in C very easily, nearly as easily
as I can in assembler.
Ok. That doesn't make C an assembler.

[...]
Yes in C I need to consider the significance of pointer types. But this
is analogous to assembler opcode options.
MOVB -- move a byte
MOVW -- move a word
MOVL -- move a longword
C assigns types to *variables*. In a typical assembler, you have to
choose the proper operation yourself; the operands don't have any type
that the assembler can use to determine which operator to use.

[...]
Actually I'd assign type short to that integer. Good point though. You
made me see I picked the wrong argument. Back to the machine with 9bit
CHAR. In C the MAX_INT is dependent on the underlying processor and is
allowed ro range up to what the hardware can handle, so instead of
32768, you can go up to 131071 Other HLLs do not let that happen. the
max int in PASCAL is 32767, even on that same machine. A High level
language was supposed to get us away from thinking about the underlying
hardware wasn't it?
No, the value of maxint in Pascal is implementation-defined. (I think
the original Pascal implementation had 60-bit ints.)

Defining specific machine-independent sizes for integer types is
actually fairly unusual; Java does this, but most other languages I'm
familiar with don't.

[...]
> PERL, BASH, SQL
> C++, JAVA
> PASCAL, FORTRAN, COBOL
> C
> assembler
> HEX opcodes
> binary opcodes
> digital voltages in the real hardware.


That seems like a reasonable scale (I might put Forth somewhere below
C). But you don't indicate the relative distances between the levels.
C is certainly closer to assembler than Pascal is, but I'd say that C
and Pascal are much closer to each other than either is to assembler.


That's it. We just differ on the scale.


Yes, we do.
I don't have a stron sense of the distances. I guess I would put C
about equidistant from both assembler and PASCAL.
No one-dimensional scale can possibly capture the nuances of a set of
dissimilar programming languages. But intuitively speaking, I still
say that C and Pascal are much closer to each other than either is to
any assembly language.

[...]
Great discussion. Thanks for the informative replies.
Ed.


Likewise.

--
Keith Thompson (The_Other_Keit h) 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.
Mar 16 '06 #231
"Alf P. Steinbach" <al***@start.no > writes:
* Keith Thompson:
"Alf P. Steinbach" <al***@start.no > writes:
C was designed as a portable assembly language, the most successful so
far, so if the term has any practical meaning, then C is that meaning.

Show us a definition of the term "assembly language". By
"definition ", I mean something that unambiguously allows you to
determine whether something is an assembly language or not. If you do
so, I predict that either (1) your definition won't apply to C, or (2)
your definition won't match any common understanding of the term
"assembly language".


Sorry, that's bullshit.

However, show me a definition of bullshit (by "definition ", I mean
something that unambiguously allows you to determine whether something
is bullshit or not) and I'll readily retract that statement. ;-)


If you're not interested in having this discussion, just say so.

If you think my request was unreasonable, please explain why.

I obviously don't know what you mean by "assembly language". I know
(more or less) what *I* mean by "assembly language", and as I
understand the term, it simply doesn't apply to C. Since you think it
does, explaining what you mean by the term would likely be helpful, at
least in establishing just where it is that we disagree.

Or you can keep swearing at me, and I can ignore you.

--
Keith Thompson (The_Other_Keit h) 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.
Mar 16 '06 #232
* Keith Thompson:
"Alf P. Steinbach" <al***@start.no > writes:
* Keith Thompson:
"Alf P. Steinbach" <al***@start.no > writes:
C was designed as a portable assembly language, the most successful so
far, so if the term has any practical meaning, then C is that meaning.
Show us a definition of the term "assembly language". By
"definition ", I mean something that unambiguously allows you to
determine whether something is an assembly language or not. If you do
so, I predict that either (1) your definition won't apply to C, or (2)
your definition won't match any common understanding of the term
"assembly language". Sorry, that's bullshit.

However, show me a definition of bullshit (by "definition ", I mean
something that unambiguously allows you to determine whether something
is bullshit or not) and I'll readily retract that statement. ;-)


If you're not interested in having this discussion, just say so.


First: we have now, satisfactorily to me, demonstrated that your request
on behalf of "us" for a really clear-cut definition of a vaguely defined
part of a term as used in contexts other than in that term, had no
bearing whatsoever on anything, other than as emotional rhetoric.

Even just the second word of that question, "us", almost blew up my
bs-meter!

So in the great American tradition, I planned to sue you -- or
somebody -- but happily the meter is now (seemingly) working again.

Then to your question, which AFAICS has nothing to do with the quoted
material:

I don't know what "the" discussion is, except it seems that some people
are being offended by having C likened to assembly language. I think
that inferiority complex could be an interesting background to various
discussions, if we just take pains to introduce that angle, e.g. how C
does not (seemingly) hold any advantage as a .NET language, and will
similarly lose terrain and become more of a specialist's niche language
when other such platforms come about, as they must. But, you want to
only discuss how the terminology evolved, or who invented it, if it was?
I'm no historian. But, one does not need to be a historian to
understand what it means: the meaning can be derived logically.

If you think my request was unreasonable, please explain why.
If you think /my/ like follow-up request was unreasonable, please
explain why.

I obviously don't know what you mean by "assembly language". I know
(more or less) what *I* mean by "assembly language", and as I
understand the term, it simply doesn't apply to C. Since you think it
does, explaining what you mean by the term would likely be helpful, at
least in establishing just where it is that we disagree.
Consider that there is an inherent conflict beween "portable" and
traditional meanings of the term "assembly language". Yes, we can
emulate one computer on another, Church and Turing showed that, but that
isn't a meaningful interpretation of "portable". And we can run virtual
machines such as JVM and CLR (or even old UCSD p-code, or LISP...) that
are essentially equivalent on all computers, and have a "JVM assembly
language" (o/w) that's effectively portable, but we don't call that a
portable assembly language -- because it's not the language that's
portable, it's the virtual machine that it's a language for. And I
could go on listing cases where "portable" isn't a meaningful addition.
E.g. saying 80386 assembly is "portable" because it can be used with a
Pentium is ridiculous, and I think you already agree to all this.

Something must therefore give, rather radically, if the term "portable
assembly" is to be meaningful, if we are to make sense of what someone
means when he or she cries "portable assembly!". And since the aim then
is to keep some meaning for "portabilit y", what must give is some of the
non-portable details usually associated with an assembly language. Away
goes register names, registers as such (but not the concept), source and
destination as part of instruction, the whole of interrupt/hardware
exception handling (it was different on different processors), i/o
instructions, any machine-specific instructions (like interlocked
increment, whatever), and so on, and voila, just add syntax to the
remains, the little core left behind, and you have C, or PL/M, or SPL,
or whatever your to-the-iron "systems language" favorite is.

Or, you can decide that the term isn't meaningful to you, and thus fail
to understand (or at least make it seem to others as if you fail to
understand) all statements made about portable assembly language.

Or you can keep swearing at me, and I can ignore you.


Ah, that's... OK! OK! I shall not say the word. You know what. ;-)

One reason why that term, "portable assembly", is still practically
useful and mentioned here and there, even on the web, is that "systems
language" has been watered down so that even original Pascal, a language
only useful for learning programming by hand-compiling simple programs,
now qualifies as a systems language.

That single reason is IMO enough to keep the term floating around, but
ironically it derives its usefulness from not being used very much, and
so not already having been watered down to mean nothing at all...

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Mar 17 '06 #233
On Thu, 16 Mar 2006 23:37:53 +0000, Keith Thompson wrote:
No one-dimensional scale can possibly capture the nuances of a set of
dissimilar programming languages. But intuitively speaking, I still
say that C and Pascal are much closer to each other than either is to
any assembly language.


I think that the thing about C that makes it "like (macro) assembler", for
me, has nothing to do with the level of control or the low-level-ness of
the feature set, although (a) that helps and (b) I think that it's been
eroded a bit, over the years, so that conforming code will run on a wider
variety of hardware.

The thing that's special about C (and perhaps Fortran and Forth) is that
what happens is what the code says to happen, nothing more. There is very
little "magic" about C. The language doesn't insert code for run-time
array bounds checks (as in Pascal, Java, most others.) The language
doesn't create invisible data structures to support it's object
abstractions (VTables and RTT-info in C++). While you can run C code with
a conservative garbage collector, like Bohem's, there isn't going to be a
magic mechanism moving things around in memory behind your back. (Well,
not unless you are using a particularly virulent interpretation of the
standard, and something like safec that has decorated pointers of some
sort.)

Even the loop constructs are basically just ways to put labels and
branches into the code. They don't even constrain the form of the
conditional expression, or the variant-update parts. Just labels and
branches.

Yes, C does do a small amount of magic. It magically marshalls arguments
onto a stack for subroutine calls, and may "promote" some along the way.
Yes, it will do a block-copy for you if you do a structure assignment.

The relative lack of magic is the important factor, IMO.

(Pascal's magic level is pretty low, too, so I do agree that it's pretty
close to C in this particular spectrum. Range checking is about the limit
of magic, here.)

--
Andrew

Mar 17 '06 #234
"Alf P. Steinbach" <al***@start.no > writes:
* Keith Thompson:
"Alf P. Steinbach" <al***@start.no > writes:
* Keith Thompson:
"Alf P. Steinbach" <al***@start.no > writes:
> C was designed as a portable assembly language, the most successful so
> far, so if the term has any practical meaning, then C is that meaning.
Show us a definition of the term "assembly language". By
"definition ", I mean something that unambiguously allows you to
determine whether something is an assembly language or not. If you do
so, I predict that either (1) your definition won't apply to C, or (2)
your definition won't match any common understanding of the term
"assembly language".
Sorry, that's bullshit.

However, show me a definition of bullshit (by "definition ", I mean
something that unambiguously allows you to determine whether something
is bullshit or not) and I'll readily retract that statement. ;-) If you're not interested in having this discussion, just say so.


First: we have now, satisfactorily to me, demonstrated that your
request on behalf of "us" for a really clear-cut definition of a
vaguely defined part of a term as used in contexts other than in that
term, had no bearing whatsoever on anything, other than as emotional
rhetoric.

Even just the second word of that question, "us", almost blew up my
bs-meter!

Then to your question, which AFAICS has nothing to do with the quoted
material:

I don't know what "the" discussion is, except it seems that some
people are being offended by having C likened to assembly language. I
think that inferiority complex could be an interesting background to
various discussions, if we just take pains to introduce that angle,
e.g. how C does not (seemingly) hold any advantage as a .NET language,
and will similarly lose terrain and become more of a specialist's
niche language when other such platforms come about, as they must.
But, you want to only discuss how the terminology evolved, or who
invented it, if it was? I'm no historian. But, one does not need to
be a historian to understand what it means: the meaning can be derived
logically.

[snip]

Apparently I have failed utterly to make myself clear. I'll try one
last time.

You claim that C is, in some sense, an assembly language
(specifically, a "portable assembly language"). I'm assuming here
that any "portable assembly language" is an "assembly language".

I claim that C is not an "assembly language", though it may bear some
resemblance to one.

I am not offended by the claim, I simply disagree with it. My
disagreement is based on my knowledge of the C programming language
and my understanding of what is meant by the term "assembly language".
(I haven't tried to provide a definition of the term myself; I might
or might not make the attempt later.)

I used the word "us" simply because we are having this discussion in a
public forum. Anything you post here will be read by multiple people,
including me -- thus "us". Nothing more.

There should be some definition of the phrase "assembly language". If
C is an assembly language, then C should meet the requirements of that
definition. This line of reasoning seems obvious and unremarkable to
me; do you disagree?

[...]
Consider that there is an inherent conflict beween "portable" and
traditional meanings of the term "assembly language". [...] Something must therefore give, rather radically, if the term "portable
assembly" is to be meaningful, if we are to make sense of what someone
means when he or she cries "portable assembly!".


I agree. It does not follow from this, though, that the term
"portable assembly language" is necessarily meaningful, or that it
applies to C even if it is meaningful.

If someone cries "portable assembly", I can either figure out what
they mean, or I can decide they're crying nonsense. I'm content to do
either or both.

So, finally, what do you mean by "assembly language"?

--
Keith Thompson (The_Other_Keit h) 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.
Mar 17 '06 #235
Andrew Reilly wrote:
.... snip ...
Yes, C does do a small amount of magic. It magically marshalls
arguments onto a stack for subroutine calls, and may "promote"
some along the way. Yes, it will do a block-copy for you if you
do a structure assignment.

The relative lack of magic is the important factor, IMO.

(Pascal's magic level is pretty low, too, so I do agree that
it's pretty close to C in this particular spectrum. Range
checking is about the limit of magic, here.)


Even lower than you think, especially when the programmer has taken
advantage of sub-ranges and typed everything as tightly as
possible. In this case a good Pascal compiler can compute the
possible range of expressions, and avoid most runtime checks. This
has the minor disadvantage of not checking for hardware errors.

--
"If you want to post a followup via groups.google.c om, 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
More details at: <http://cfaj.freeshell. org/google/>
Also see <http://www.safalra.com/special/googlegroupsrep ly/>
Mar 17 '06 #236
* Keith Thompson:

You claim that C is, in some sense, an assembly language
Nope, as you know I haven't claimed that. Whenever you're referring to
a claim, be sure to quote that claim. Especially when your previous
attempt at making the claim-making stick has been shown as fallacious.

(specifically, a "portable assembly language").
I'm assuming here that any "portable assembly language" is an "assembly language".
That assumption does not hold.

However, that was explained twice, in detail, in the posting you now
replied to, and yet here you are making the same nonsense assumption.

OK, example.

Example 1.

Cheery Unstoppable Keith: "How's your cycle, by the way?"
Puzzled Maria: "Fine, just fine?"
Cheery Unstoppable Keith: "So you don't share it with others?"
Puzzled Maria: "That happened five years ago, when we all
lived together. You want to borrow it?"
Cheery Unstoppable Keith: "Huh, you think I'm transsexual!?!"
Puzzled Maria: "/What/?"
Cheery Unstoppable Keith: "Don't try that on me! I know what you're
thinking! What you're /implying/!"
Puzzled Maria: "Uh oh... Keith, say, you'd like a beer or
something? I'll go fetch it. Right back!"

In this highly educational example, note that the "MotorCycle " that
Puzzled Maria is thinking of, is not a "Cycle" that Cheery Unstoppable
Keith is thinking of. Just chopping off the word "Motor" does not make
a "MotorCycle " into a "Cycle". Well, OK, it does, but not /that/ kind.

I have numbered this example in case more examples will be needed; then
the numbers may make it easier to refer unambigiously to the examples.
[snip] There should be some definition of the phrase "assembly language".
Try <url: http://en.wikipedia.or g/wiki/Assembly_langua ge>; although not
a reference nor of reference-quality, it's good enough for any novice
level in-practice discussion or just learning what the term means very
roughly.

If
C is an assembly language, then C should meet the requirements of that
definition. This line of reasoning seems obvious and unremarkable to
me; do you disagree?
No, I don't disagree; it's fine on its own, and it's irrelevant.

[...]
Consider that there is an inherent conflict beween "portable" and
traditional meanings of the term "assembly language". [...]
Something must therefore give, rather radically, if the term "portable
assembly" is to be meaningful, if we are to make sense of what someone
means when he or she cries "portable assembly!".


I agree. It does not follow from this, though, that the term
"portable assembly language" is necessarily meaningful, or that it
applies to C even if it is meaningful.

If someone cries "portable assembly", I can either figure out what
they mean, or I can decide they're crying nonsense. I'm content to do
either or both.


Yes, you can either assume some meaning, in which case you'll end up
with essentially my analysis (perhaps differing in some detail), and
will be able to understand e.g. that Wikedia article referred to earlier
in the thread, which used that (to you) troublesome term.

Or, you can say, I regard this term as meaningless, I refuse to consider
any meaning, I want to be forever ignorant except as enlighened by some
of my chosen Holy Books (e.g. the C and perhaps C++ standards).

So, finally, what do you mean by "assembly language"?


I think that should be clear since I've now used the term, but one
important difference from the Wikipedia definition is that I do regard
e.g. "CLR assembly language" (CIL, Common Intermediate Language) as an
assembly language, i.e. I include assembly languages for virtual
machines among the assembly languages, and I do not exclude assembly
languages that have some OO features, such as TASM had and CIL has.

However, note well again for the umpteenth time (some time it must sink
in, I hope) that that's irrelevant: I only answer it because you ask.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Mar 17 '06 #237
"Alf P. Steinbach" <al***@start.no > writes:
* Keith Thompson:
You claim that C is, in some sense, an assembly language


Nope, as you know I haven't claimed that. Whenever you're referring
to a claim, be sure to quote that claim. Especially when your
previous attempt at making the claim-making stick has been shown as
fallacious.


Here's what you wrote upthread:

] C was designed as a portable assembly language, the most successful so
] far, so if the term has any practical meaning, then C is that meaning.
]
] C was designed as a portable assembly language for the purpose of
] porting Unix (which then had some seven or ten installations, I
] forget, but one rumor has it there was only one, namely the PDP-7)
] more easily. That didn't fully remove the need for using actual
] assembly. But only some small parts still needed to be
] machine-specific assembly.
(specifically, a "portable assembly language"). I'm assuming here
that any "portable assembly language" is an "assembly language".


That assumption does not hold.


So you're using the term "portable assembly language" while insisting,
in contradiction to ordinary English grammar, that a "portable
assembly language" is not necessarily an "assembly language".
("Portable" is an adjective; "assembly language" is a noun phrase.)
And yet you seem surprised that I'm having trouble figuring out what
you're talking about.

I'm done here.

--
Keith Thompson (The_Other_Keit h) 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.
Mar 17 '06 #238
* Keith Thompson:

So you're using the term "portable assembly language" while insisting,
in contradiction to ordinary English grammar, that a "portable
assembly language" is not necessarily an "assembly language".
If it were as want it to be, then "portable assembly" would be a
contradiction in terms... :-o

You cannot extract meaning or conclude from a self-contradiction.

By the rules of logic, that is.

("Portable" is an adjective; "assembly language" is a noun phrase.)
And yet you seem surprised that I'm having trouble figuring out what
you're talking about.
Yes, you have managed to suprise me continuously. Nobody can be that
stubborn, I think. And yet you come through; ignoring logic, ignoring
examples, ignoring established usage, insisting that your own extremely
little irrelevant subset of language rules is what "should" apply.

I'm done here.


Well done, I might add. If not to say roasted.
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Mar 17 '06 #239
"Alf P. Steinbach" <al***@start.no > wrote:
* Richard Bos -> someone:

*Shrug* If you go about redefining terms to support your delusion that C
is a portable assembler, that's your problem, not that of C.
Happily I haven't followed this debate, so I don't know what you folks,
good or not, think "portable assembler" means, nor how you can think a
language is a compiler (or whatever).

C was designed as a portable assembly language,


Complete nonsense. Read what dmr himself writes about this:
<http://cm.bell-labs.com/cm/cs/who/dmr/chist.html>.

C was designed as a systems programming language for (then) a single,
new OS, _not_ a portable assembler. In fact, that article explicitly
states that a. one of the reasons that drove the evolution of C's
ancestors, and later C itself, was _not_ to have to use assembler and b.
portability was not yet a concern in the first days.
You can find more information about the C language at e.g. Wikipedia,
<url: http://en.wikipedia.or g/wiki/C_programming_l anguage>.


Ah, well, yes, if you get your information from Wikipedia, where any
little fool with a complete misunderstandin g of his subject can, and
last time I looked at that page in fact _had_, turned an article into a
mix of some seeds of fact, some serious misconceptions, and quite a bit
of complete bollocks, then I'm afraid I cannot take your opinion on any
subject seriously, certainly not on C.

Richard
Mar 17 '06 #240

This thread has been closed and replies have been disabled. Please start a new discussion.

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.