How to convert Infix notation to postfix notation

[spinoza1111]

 >
 > > It's not, but my new style (which isn't really new, but is of the sort
 > > found in more academic books) doesn't suck. It's laid out for
 > > readability, uses the right form of Hungarian and is easy for
 > > intelligent people to read.
 >
 > Which books use your style of function declarations and
 > definitions?

Perhaps "Build Your Own .Net Language and Compiler"?  ;-)

Great book, praised for its style: A Customer at Amazon writes: "This
book contains a huge amount of code that has obviously been under
development and evolving for a long time. The code has a level of
documentation, error checking and self-consistency testing that is
rare to see even in commercial code, much less sample code for a
book."

The book has been selling consistently for five years ranking between
750,000 and 250,000. Often when I've randomly checked its numbers, it
is mentioned in the top 20 and sometimes top ten Compilers books: once
it was adjacent to Aho Sethi Ullman (I'm not worthy! I'm not worthy!).
I've been banking royalty checks for years on this book despite the
fact that the Amazon site was deliberately spammed by people here with
negative reviews.

[Gee how is Richard Heathfield's famous C Unleashed doing? Hmm 984000
and change rankwise. Also, it appears to have gone out of print, since
I cannot order it through Amazon. Of course, it was published in 2000,
and I may myself be out of print in 2013: all flesh is grass.]

But, in recent years, owing to the precedent set by Seebach wrt
Schildt, Twerps Withour Standing have gotten around, in recent years,
to analyzing my code for sins of ommission and commission. Some
genuine problems that the Twerps have noticed include the use of
weakly typed Collections.

The original .Net and pre-.Net collection contained Objects and your
could add any sort of garbage to them. Their precedent in Visual Basic
was the Variant, which could contain "anything" and caused as much
damage if not more than the void pointer of C.

But what bothered the Twerps was the extra code for inspect() which
rummaged through Collections making sure that in fact each Object in
the traditional Collections was of proper type: furthermore, if this
type was itself other than what I called scalar in the book (a basic
type, suitable to being placed as-is on the Stack) the object was
subject to its own inspect().

The Twerps howl on the site that I should have used Generics. The
problem being that the code was written in 2002 when there were not
Generics: these date in their full glory from 2005 and they are great:
they allow you to declare a collection of objects of type foo as
Collection<foo>.

The book is in its humble way helping people learn. This bothers only
Twerps and gives me a good feeling.

 

[spinoza1111]

I wonder if that book is full of weird diatribes and references
to John Nash?

Find out. Buy a copy! I'd send you twerps a free one, but it's out of
the question, isn't it?

Seriously, it confirms that Nixon invaded Cambodia, because that's
what Nixon did when I was taking CS 101 and trying to sort out a
broken Fortran compiler (which I fixed two years later) and a textbook
which talked about the IBM 7094, which my uni did not have. That
bastard was a great President compared to Reagan or Bush.

 

[spinoza1111]

Judging by the reviews, it's saner.

Fair and Balanced, Peter. Thanks. Some of the reviewers hate it but
some like it. It's a cult classic, like Plan Nine from Outer Space.

 

[spinoza1111]

"io_x" <[email protected]> ha scritto nel messaggio

"spinoza1111" <[email protected]> ha scritto nel messaggio

   testCase("((10+(113-(2+((((((2/(4+3)))))))+2+2))))*a", "10 113 2 2
4 3 + / + 2 + 2 + - + a *", intMallocMax);

why this above not result to me?

i think for the same reason that
"a+b-c"
for spinoza prog it is  "a b + c -"
for the asm prog it is  "a b c - +"
so the asm prog is "right to left"
but spinoza prog will be "left to right"?

i fix 2 bugs for input arguments
-----------
; reference in Robert Sedgewick "Algoritmi in C"
; nasmw -fobj  thisfile.asm
; bcc32 thisfile.obj

%define  P  _printf

section _DATA use32 public class=DATA
global _main
extern _printf
extern _fgets
extern __streams
; _streams+ 0 = stdin
; _streams+24 = stdout

%define  Space    6
%define  Digit    0
%define  Operator 3

ptr:  dd v1, v2, v3, v4, v5, v6

;    0,  1,  2,  3,  4,  5,  6,  7,  8,  9
Table:
db 16, 16, 16, 16, 16, 16, 16, 16, 16, 6 ;  0
db 6, 16, 16, 6, 16, 16, 16, 16, 16, 16 ;  1 10 e' fine input non spazio
db 16, 16, 16, 16, 16, 16, 16, 16, 16, 16 ;  2
db 16, 16, 6, 16, 16, 16, 16, 3, 3, 16 ;  3
db 1, 2, 3, 3, 16, 3, 16, 3, 0, 0 ;  4 "." e' lettera
db 0, 0, 0, 0, 0, 0, 0, 0, 16, 16 ;  5
db 16, 16, 16, 16, 16, 0, 0, 0, 0, 0 ;  6
db 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 ;  7
db 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 ;  8
db 0, 16, 16, 16, 3, 0, 16, 0, 0, 0 ;  9
db 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 ; 10
db 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 ; 11
db 0, 0, 0, 16, 3, 16, 16, 16, 16, 16 ; 12
db 16, 16, 16, 16, 16, 16, 16, 16, 16, 16 ; 13
db 16, 16, 16, 16, 16, 16, 16, 16, 16, 16 ; 14
db 16, 16, 16, 16, 16, 16, 16, 16, 16, 16 ; 15
db 16, 16, 16, 16, 16, 16, 16, 16, 16, 16 ; 16
db 16, 16, 16, 16, 16, 16, 16, 16, 16, 16 ; 17
db 16, 16, 16, 16, 16, 16, 16, 16, 16, 16 ; 18
db 16, 16, 16, 16, 16, 16, 16, 16, 16, 16 ; 19
db 16, 16, 16, 16, 16, 16, 16, 16, 16, 16 ; 20
db 16, 16, 16, 16, 16, 16, 16, 16, 16, 16 ; 21
db 16, 16, 16, 16, 16, 16, 16, 16, 16, 16 ; 22
db 16, 16, 16, 16, 16, 16, 16, 16, 16, 16 ; 23
db 16, 16, 16, 16, 16, 16, 16, 16, 16, 16 ; 24
db 16, 16, 16, 16, 16, 16, 16, 16, 16, 16 ; 25

          IstartIIIsIIIresultIIIsIIIn
db "start [%s]; result [%s] " , 13, 10, 0

          IErrorIinIcharIIdIIErrstrIIsIn
db "Error in char %d  str=%s" , 13, 10, 0

v1:
          IErroreIdiIargomenti
db "Errore di argomenti" , 0

v2:
          IErroreItroppiIoperatoriIII4028I
db "Errore troppi operatori (>4028)" , 0

v3:
          IErroreIoverflowIresult
db "Errore overflow result" , 0

v4:
          IErroreIIIIIIIIInonIbilanciate
db "Errore '(' ')' non bilanciate" , 0

v5:
          IErroreIalternanzaInonIrispettata
db "Errore alternanza non rispettata" , 0

v6:
          IErroreIcarattereInonIpermesso
db "Errore carattere non permesso" , 0

section _BSS use32 public class=BSS

section _TEXT use32 public class=CODE

;Errore se ritorna !=0
; Caso 1: Errore di argomenti
; Caso 2: Errore troppi operatori (>4028)
; Caso 3: Errore overflow result
; Caso 4: Errore '(' ')' non bilanciate
; Caso 5: Errore alternanza non rispettata
; Caso 6: Errore carattere non permesso
;0k,4j,8i,12b,16ra,20Pres,24PresSz,28P_PLen,32P_i+16
;                  36     40       44       48
          align   4
infixToPolishAsm:
          push    ebx
          push    esi
          push    edi
          push    ebp
          sub     esp,  16
          mov     edi,  dword[esp+  36]
          mov     ebp,  dword[esp+  40]
          mov     esi,  dword[esp+  48]
          mov     ecx,  esp
          mov     dword[esp],  0
          mov     dword[esp+4],  0
          mov     dword[esp+8],  0
          xor     eax,  eax
          xor     ebx,  ebx
          mov     edx,  1
          cmp     dword[esp+  44],  0
          je      .e0
          cmp     edi,  0
          je      .e
          cmp     ebp,  1
          jle     .e
          mov     byte[edi],  0
          cmp     esi,  0
          je      .e
          jmp     .3
.e:       sub     esi,  dword[esp+  48]
          mov     edi,  dword[esp+  44]
          mov     [edi],  esi
.e0:      mov     eax,  edx
          stc
          jmp     .z
.e1:      mov     esp,  ecx
          mov     byte[edi],  0
          mov     edx,  2
          jmp     short  .e     ; errore: overflow stack
.e2:      mov     esp,  ecx
          mov     byte[edi],  0
          mov     edx,  3
          jmp     short  .e     ; errore: overflow res
.e3:      mov     esp,  ecx
          mov     byte[edi],  0
          mov     edx,  4
          jmp     short  .e     ; errore: ( non bilanciate
.e4:      mov     esp,  ecx
          mov     byte[edi],  0
          mov     edx,  5
          jmp     short  .e     ; errore: alternanza non rispettata
.e5:      mov     esp,  ecx
          mov     byte[edi],  0
          mov     edx,  6
          jmp     short  .e     ; errore: carattere non permesso
.0:       mov     byte[edi],  0
          cmp     dword[ecx],  0
          jne     .e3
          cmp     dword[ecx+4],  1
          jne     .e4
.0x:      cmp     ecx,  esp
          je      .0a
          pop     edx
          mov     byte[edi],  ' '
          dec     ebp
          jle     .e2
          inc     edi
          mov     byte[edi],  dl
          dec     ebp
          jle     .e2
          inc     edi
          mov     byte[edi],  0
          jmp     short  .0x
.0a:      sub     edi,  dword[esp+  36]
          mov     edx,  dword[esp+  44]
          mov     [edx],  edi
          xor     eax,  eax
          jmp     .z
.2:       inc     esi
.3:       mov     al,  [esi]
.0b:      cmp     eax,  0
          je      .0
          mov     bl,  [Table+eax]
          cmp     ebx,  Space
          je      .2
          cmp     ebx,  Digit
          jne     .2a
          add     dword[ecx+4],  1
          cmp     dword[ecx+4],  1
          jg      .e4
.1a:      mov     [edi],  al
          inc     esi
          mov     al,  [esi]
          dec     ebp
          jle     .e2
          inc     edi
          cmp     byte[Table+eax],  0
          je      .1a
          jmp     short  .0b
.2a:      cmp     ebx,  Operator
          jne     .4
          sub     dword[ecx+4],  1
          cmp     dword[ecx+4],  0
          jl      .e4
          mov     edx,  ecx
          sub     edx,  esp
          shr     edx,  2
          cmp     edx,  4028
          jae     .e1
          push    eax
.3a:      mov     byte[edi],  ' '
          dec     ebp
          jle     .e2
          inc     edi
          jmp     .2
.4:       cmp     eax,  ')'
          jne     .5
          cmp     dword[ecx],  0
          je      .e3
          inc     dword[ecx]
          cmp     esp,  ecx
          ja      .e
          jz      .2
          pop     edx
          sub     ebp,  2
          jle     .e2
          mov     byte[edi],  ' '
          inc     edi
          mov     byte[edi],  dl
          inc     edi
          jmp     .2
.5:       cmp     eax,  '('
          jne     .e5
          dec     dword[ecx]
          jmp     .2
.z:
          lea     esp,  [esp+16]
          pop     ebp
          pop     edi
          pop     esi
          pop     ebx
          ret     16

          align   4
_main:
          pushad
          sub     esp,  4048
          mov     edi,  esp
          lea     esi,  [edi+2000]
          lea     ebp,  [edi-4]
          push    __streams
          push    1024
          push    esi
          call    _fgets
          add     esp,  12
          cmp     eax,  0
          je      .x
          jmp     short  .1
.e:       dec     eax
          cmp     eax,  5
          ja      .x
          mov     edx,  [ptr+4*eax]
          mov     eax,  [ebp]
          push    edx
          push    eax
          push    IErrorIinIcharIIdIIErrstrIIsIn
          call    P
          add     esp,  12
          jmp     short  .x
.1:       push    esi
          push    ebp
          push    1024
          push    edi
          call    infixToPolishAsm
          cmp     eax,  0
          jne     .e
          push    edi
          push    esi
          push    IstartIIIsIIIresultIIIsIIIn
          call    P
          add     esp,  12
.x:
          add     esp,  4048
          popad
          xor     eax,  eax
          ret

Wow, pretty impressive assembler. I can confirm hastily (writing from
Starbuck's that my code is left associative. But don't use its results
as a benchmark or an authority. The code is a work in progress.

 

[Seebs]

I was hoping for the long explanation.

Me too.

My comment wasn't meant to be inflammatory, I just thought it was an
interesting discussion.

http://www.embeddedarm.com/software/arm-netbsd-toaster.php

An actual, literal, toaster, with a working operating system, accepting
keyboard input.

Anyway, here's the thing. The reason I consider those embedded things
"computers" is this: When I was a little kid, I used to go up to the
college my dad worked at, sit on a phonebook, and play rogue on a large
system shared by many users.

I feel comfortable asserting that any device which has a faster CPU and
more memory than those devices ought to be counted as a "computer". It's
a thing which processes digital signals in a fairly general way, using
memory to store both code and data, it takes inputs, performs computations,
and produces outputs... It's a computer. That the inputs aren't mouse
clicks or keystrokes doesn't change that.

Note that ordinary toasters aren't computers; they're purely mechanical
gizmos with no real control logic. On the other hand, the toaster oven
I got a while back definitely contains a computer. Not a very advanced
one, sure, but it's a computer. It is entirely conceivable that the
code which decides what to do based on button presses was compiled by a
C compiler.

-s

 

[spinoza1111]

That isn't necessarily a good guide, especially as the author has
confessed to writing one of the reviews and may well have written

Let me clarify what happened lest this THUG again obscure the truth.

I wrote one positive review under a pseudonym when persuaded to do so
by a coworker up in China. My main review under my own name gave
myself four stars because I didn't have enough time to cover object
code generation in full.

I later asked Amazon to withdraw the pseudonym review having decided
that it was venially dishonest, but dishonest, to post this review,
even though (according to an article in the New Yorker) several well
known authors who are otherwise ethical have done this: post favorable
reviews of their own work from pseudonymical accounts.

These authors do so because the Internet gives a false authority to
people without standing (such as Peter Seebach and the attackers of
Java author Kathy Sierra) and they need to defend their livelihoods.

My Chinese coworker felt I was justified because he saw the deliberate
spams at the booksite. However, I feel that it is best to verbally
self-defend and not be dishonest.

Richard Heathfield is consistently dishonest, especially as regards
other people's qualifications and their "errors", which he delights in
exagerrating and in fabricating. For example, Heathfield lied when he
claimed that it took me any time at all to see the so-called "bug" of
relying on Microsoft file case insensitivity, and Heathfield lied when
he claimed that "not using const" was a bug.

Heathfield appropriated the first "error" from another's research, and
he found the second by mindlessly running a compiler with rich
warnings in effect. His modus operandi is to break into discussions
where he is not wanted, and then to steal others' bug reports, making
them into global claims about the competence of people Heathfield
targets. This behavior, I am confident, is going land him in a UK
courtroom which takes a dim view of civil and criminal libel.

I hope that this clears this matter up.

 

[spinoza1111]

Yeah, I think at this point I'm convinced that it's simply not *possible*
for him to justify a position.

That said...

I think it was all worth it to get the Stroustrup quote.


This will be, for some time, my gold standard example of the non-sequitur,
just as Spinny himself is my gold standard example of the Dunning-Kruger
effect.

Then the New York times deals in "non-sequiturs"? My source:

http://www.nytimes.com/2002/08/14/obituaries/14NYGA.html?scp=7&sq=stroustrup&st=cse

[Article reproduced in full below]

For little clerks who aren't really programmers, it's in effect a "non-
sequitur" to so much as name something so ... scarey ... as a labor
union, but the New York Times confirms that the origin of C++ lies in
Stroustrup's participation in Simula, and Simula was developed so that
little "programmers" couldn't deceive union members and workers, and
install some C-like crap in factories that endangered their lives or
livelihoods.

Since apart from that, he appears to be a liar, an idiot, probably
insane, and completely incapable of supporting his points, as well as
awe-inspiringly ignorant of C... I'm done with that. Back in the
killfile with him.

**** you, asshole: **** you very, very much. And, you're lying.

... Which is not to say there will be NO productive output from this. I've
tracked down a used copy of C:TCR 4th Edition, and I'll be updating the
page accordingly.

Kristen Nygaard, Who Built Framework for Computer Languages, Dies at
75
By JOHN MARKOFF
Published: Wednesday, August 14, 2002
Sign in to Recommend
Twitter

E-Mail


Reprints

Share
Close
LinkedinDiggFacebookMixxMySpaceYahoo! BuzzPermalinkKristen Nygaard, a
Norwegian mathematician who laid the groundwork for modern computer
programming languages and who helped Scandinavian workers influence
the design of labor-saving computer technologies, died on Saturday in
Oslo, Norway. He was 75.

The cause of death was a heart attack, said Ole Lehrmann Madsen, a
friend and colleague at Aarhus University in Denmark.

From 1962 to 1967, with his co-worker Ole-Johan Dahl, Mr. Nygaard
designed Simula, a programming language intended to simulate complex
real-world systems. The ideas underlying Simula emerged from Mr.
Nygaard's work in the area of operations research while he was
employed at the Norwegian Defense Research Establishment from 1948 to
1960.

Although the original use for Simula was a physics simulation for a
military laboratory, workers at the Norwegian Iron and Metal Union
approached Mr. Nygaard, in the late 1960's with concerns about
computers in displacing and altering their jobs. Mr. Nygaard began
working with them, pioneering an approach that became known as
participatory design, in which workers help design new technologies in
the workplace.

"It was originally thought of as a socialistic movement," said Dr.
Madsen, who worked with Mr. Nygaard over several decades. "However,
eventually large corporations began to realize this was a reasonable
practice and it is widely used around the globe today."

Simula was significant for pioneering the concept of "object oriented"
programming. Before Simula, computer programs were thought of in terms
of software instructions and data. Simula introduced the idea of
objects, or modules, and classes of objects. Such object-based
programs made it easy for programmers to reuse software, thus
dramatically increasing productivity and efficiency.

"He understood that simulation was the ultimate application of
computers," said Larry Tesler, a computer scientist who has worked at
the Xerox Corporation and Apple Computer . "It was a brilliant
stroke."

Simula would ultimately influence the designers of a wide range of
programming languages, including Smalltalk, C++, and Java, and it
would leave a deep impression on the personal computer world as well,
influencing the designers of both the Macintosh and Windows operating
systems.

As a graduate student at the University of Utah, the computer
scientist Alan Kay became familiar with Simula, which was to become
one of the principal influences on Smalltalk, an object-oriented
programming language he developed with a small group of programmers at
Xerox's Palo Alto Research Center in the early 1970's. Because Simula
permitted the creation of classes of objects and permitted
"inheritance," in which all the objects of a class could automatically
take on certain attributes, it led Dr. Kay to begin thinking in
biological terms. He conceived of software in a framework where
complex processes could emerge from simple building blocks.

The Palo Alto research in turn influenced a generation of computer
designers at both Apple Computer and the Microsoft Corporation in the
early 1980's, when the modern personal computer was taking form.

Several years after Dr. Kay discovered Simula, Bjarne Stroustrup, a
Danish programmer who studied at Cambridge and who would later become
a software designer at Bell Laboratories, also encountered the
language. Like Dr. Kay, he would be influenced by the idea of software
objects, and he would build that concept into his widely influential C+
+ programming language.

Kristen Nygaard was born on Aug. 27, 1926, in Oslo. He received his
master's degree in mathematics at the University of Oslo in 1956.

He taught in both Denmark and at the University of Oslo, where he was
a professor until he retired until 1996.

In the 1970's, Mr. Nygaard's research interests increasingly turned to
the impact of technology on the labor movement, and he became involved
in other political, social and environmental issues. He was the first
chairman of the environment protection committee of the Norwegian
Association for the Protection of Nature. He was also the Norwegian
representative for the Organization for Economic Cooperation and
Development's activities on information technology.

He also helped run an experimental program to create humane living
conditions for alcoholics.

In the mid 1960's he became a member of the National Executive
Committee of the Norwegian party Venstre, a left-wing non-socialist
party, and chairman of that party's strategy committee. In 1988 he
became chairman of a group that successfully opposed Norway's
membership in the European Union.

This year, with Ole-Johan Dahl, Mr. Nygaard shared both the
Association of Computing Machinery's Turing Award and the Institute
for Electrical and Electronics Engineers von Neumann Medal. In 1990
the Computer Professionals for Social Responsibility awarded him the
Norbert Weiner Prize.

He is survived by his wife, Johanna Nygaard, three children and seven
grandchildren

 

[Nick Keighley]

Nick Keighley wrote:

 >> Actually I've little idea what a server is.
 >
 > a usually rack mounted computer, usually placed in an air conditioned
 > room. Google for instance has rooms full of 'em. All large businesses
 > have tons of em too that do everything from tracking inventory to
 > issuing invoices to printing the wage checks. The world has been
 > running on this stuff since about 1960.

"Server" is a role that a computer performs.

News messages are downloaded from an NNTP "server".  Hostnames are
resolved to IP Addresses by a DNS "server".

What hardware is used to do the job is totally irrelevant.

it is nevertehless a widely used term

http://welcome.hp.com/country/us/en/prodserv/servers.html

(I equally have posted a Dell, Intel or half a dozen other hardware
manufacturers). Wikipedia agrees with you though

we need a term for "heavy duty back office hardware" and mainframe is
out of fashion

 

[spinoza1111]

In

spinoza1111wrote:


Rubbish. Dennis Ritchie is a counter-example, as he was a C expert
before Microsoft was even founded. Proof: dmr has published the
source to two C compilers dated around 1972-1973, which shows that C
existed at that time. That dmr was expert in C at that time is
indisputable. Microsoft was founded in 1975.

This makes NO sense, since the question isn't whether Microsoft
invented C (it didn't). It is whether knowledge of Microsoft platforms
is required for true C expertise, and the large amount of C code
running on Microsoft platforms means it is.

For example, a true C expert knows that a C program, given C's access
to low-level, machine and OS dependent facilities, cannot be
mindlessly ported. Suppose he's given the task of porting a Microsoft
C program to a non-Microsoft platform.

One of the first issues on his to-do list will be to check all file
identifiers identified in the code for case, and to make sure this
matches the case in use in the non-Microsoft environment! This is
because he knows that sensitivity to case differs across "the two
cultures".

He will also check newline usage for the difference between the
(traditional and being phased out) Microsoft use of carriage return,
line feed to mark line boundaries in many files, and the use of
linefeed in other platforms.

He won't have time to whine about Microsoft in some fashionable
register. He will also buy the 4th edition of Schildt's "C: The
Complete Reference" to find Microsoft-centric issues for follow up.

This has an interesting result: it means that the C expert of clc in
terms of crossing the culture divide is Edward G. Nilges. From 1981
through 2005 I worked in multivendor environments across this divide,
and I've also crossed the line into the IBM mainframe line.

Or, more precisely, I am well on the way IF I persist in coding C on
the ferry, and ramp back up to a former level of knowledge. This may
not happen because when I code C I have an urge to kick small animals
and break up Salvation Army meetings; so much of C is an insult to
intelligence.

 

[spinoza1111]

In



Yes, it does. I do not expect you to understand this.


Right, it isn't.


Right again - twice in a row is pretty good for you. The argument
above shows that C expertise can occur even in the complete absence
of Microsoft. It's an obvious argument, and it's self-evidently true,
but don't let that stop you from misunderstanding it.

Are you dumb, stupid, retarded or brain damaged?

Prior to the first Microsoft compiler there were C experts such as
dmr. But to be a C expert today, you need to know the Microsoft
platform differences.

I'm using "expert" in the normative, not descriptive sense. That is,
I'm not talking about C programmers who "think" they are experts. Nor
am I talking about C programmers who are regarded as experts by some
workgroup, or within this dysfunctional community clc. I mean someone
who is genuinely knowledgeable about a wide spectrum of applications.

And I'm saying that people with fashionable hatreds and shibboleths
aren't even emotionally mature grownups. Rather, with jobs that
constitute welfare for white males, they believe that they can
gerrymander and redefine reality so as to make themselves experts in a
sufficiently well-defined game.

I'm not even sure that dmr is truly an expert...any more. And, Brian
Kernighan's remarks in Beautiful Code about the putative superiority
of C to Java based on "efficiency" commits, as far as I'm concerned,
one of the oldest sins in the computing book: the prizing of
efficiency over correctness and elegance.

If one insists that a field be artificially bounded so that one is an
authority, one lacks expertise.

 

[Seebs]

of your own book

Hey, I did that too!

.... but not that.

because you didn't want people to know it was the author praising his
own book.

Whereas I thought it would be hilarious, so I submitted a review under
the title "Best book I ever wrote." I feel that any concerns about
full disclosure are adequately addressed by the opening paragraph:

Having heard that authors frequently review their own books,
I thought I'd give it a try. This is, without a doubt, the
best book on portable shell scripting I have ever written.
Sadly, it is also the worst book on portable shell scripting
I have ever written.

-s

 

[spinoza1111]

In



No, you're just projecting again.


Not so. The language is independent of any particular platform. Again,
I do not expect you to understand this.



If anyone else were to say that, I'd be astounded. That you say it
comes as no surprise.


"Today, machines are much cheaper and faster, so the need for absolute
efficiency is greatly reduced. Is it still worth worrying about
performance? Yes, but only if the problem is important, the program
is genuinely too slow, and there is some expectation that it can be
made faster while maintaining correctness, robustness, and clarity. A
fast program that gets the wrong answer doesn't save any time." -
Brian W Kernighan and Rob Pike, "The Practice of Programming".

And so yet another of your campaigns of personal destruction is shown
to have no basis whatsoever.


You seem to think that expertise is about reputation rather than
knowledge of one's field.

At a dinner party, the hostess introduced one of her guests to the
others as "an expert on crocodiles". He replied, "Madam, you do me
too much honour - it is only the crocodile's eyebrows on which I am
an expert." The fact that he has chosen to specialise in a narrow
field does not mean he is not an expert in that field. When compared
to "C on all platforms", the C language itself is indeed a narrow
field. Nevertheless, it is sufficiently wide that expertise in
platform-independent C is well worth having. Your attempts to be rude
about it don't change that fact.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within

You don't see where this logic is leading. If it's possible for the
"expert" to define his area of competence, here to ignore C-on-
Microsoft and case insensitive file ids, then he has no standing in
criticising a book which as a practical proposition was about C on the
most common platform.

This was Seebach who in his Vitriolic Tirade did not include a
disclaimer about his expertise, instead assumed through apparent
ignorance that all platforms will penalize a programmer who uses the
wrong case pattern.

 

[Rod Pemberton]

C defines a byte as being large enough to hold any member of the basic
character set of the execution environment.

"to hold"

Not to access. C can't access bytes, except for the the null character. C
can access characters as part of a string. I.e., a byte can be larger than
a char in size, but a string in the C context isn't comprised of bytes but
of characters - characters being the portion of a byte the C context can
recognize.


Rod Pemberton

 

[Keith Thompson]

"to hold"

Not to access. C can't access bytes, except for the the null character. C
can access characters as part of a string. I.e., a byte can be larger than
a char in size, but a string in the C context isn't comprised of bytes but
of characters - characters being the portion of a byte the C context can
recognize.

No, a byte cannot be larger than a char in size. sizeof(char) == 1
(byte) *by definition*. Type unsigned char cannot have padding bits;
an object of type unsigned char can have one of exactly 1<<CHAR_BIT
distinct values. I think that plain char or signed char also cannot
have padding bits.

Certainly C can access bytes; just declare an unsigned char, or an
array of unsigned char.

 

[Nick Keighley]

"to hold"

Not to access.

that's just crap. If you can't read it back in what sense does it
"hold" something. This reminds me of the $ETHNIC_GROUP joke about WOM
chips, Write Only Memory.

 C can't access bytes, except for the the null character.

yes it can. Everything you say is wrong. If you use the C definition
of a byte (equal to a char) or the common definition of a byte (8
bits), in which case char may be *larger* than a byte

 C can access characters as part of a string.
yes

 I.e., a byte can be larger than a char in size,

never ever ever. Unless you are using pre-1980 bytes? 6-bit bytes?

but a string in the C context isn't comprised of bytes

oh yes it is

but of characters -

actually chars. Characters might be unicode or something.

characters being the portion of a byte the C context can
recognize.

rubbish

 

[spinoza1111]

In

spinoza1111wrote:

If one insists that a field be artificially bounded so that one
is an authority, one lacks expertise.
You seem to think that expertise is about reputation rather than
knowledge of one's field.
[...] When
compared to "C on all platforms",

...which on reflection is a touch ambiguous, but I think we both know
that I meant "C plus all the platform-specific knowledge needed to
make C do things that the language spec doesn't cover, for any and
all platforms"...

You don't see where this logic is leading.

Sure I do.

If it's possible for the "expert" to define his area of competence,
here to ignore C-on-Microsoft and case insensitive file ids,

The word "expert" is rather like the word "hacker" (in the canonical
sense) - it is far more informative when knowledgeable disinterested
parties use it to describe X than when X uses it to describe himself
or herself. If Y describes X as an expert on, say, D-H key exchange,
the fact that D-H key exchange is a tiny, tiny part of cryptography
does not make Y's description any less true.

If you want to discuss C-on-Microsoft, I suggest a Microsoft
programming newsgroup, of which there are many. As for
case-insensitive file ids, that's a red herring - your fault lay in
ignoring case-sensitive systems, not case-insensitive systems. There
are two ways to type the h in <stdio.h> - lower case or upper case.
Lower case is guaranteed to work EVERYwhere, and upper case isn't
guaranteed to work ANYwhere, but does happen to work on some systems.
Which of the two is preferable is so blindingly obvious that only a
truly ignorant programmer could get it wrong.

then he has no standing in
criticising a book which as a practical proposition was about C on
the most common platform.

You're talking rubbish again. It might be an idea for you to read the
book before writing about it.

CTCR is advertised (on its front cover) as being "ideal for all C
programmers". And on page 1 we find: "The material in this section
(and most of the material in the book) reflects the ANSI standard for
C. However, the original C standard as derived from the Unix version
5 C is also covered, and important differences are noted. The book
covers both ANSI and the original C to ensure that you find
information relevant to your C programming environment."

In the contents list, Unix is mentioned twice in the Chapter 9
contents summary. Windows isn't mentioned at all, and DOS is not
mentioned until the contents summary of Chapter 24. The first
occurrence in the book of the word "Microsoft" (context: "The Calling
Conventions of Microsoft C") is in the contents summary for Chapter
26.

This was Seebach who in his Vitriolic Tirade did not include a
disclaimer about his expertise, instead assumed through apparent
ignorance that all platforms will penalize a programmer who uses the
wrong case pattern.

Learn to read. His argument was very different: NO platforms will
penalise a programmer who uses the RIGHT case pattern.

These questions are not rhetorical. I want a straight answer from you.
Consider yourself on a witness stand as you yet might find yourself on
the hot seat.

(1) At the time CTCR was first written, did the "standard" mandate
that (for example) "stdio.h" and other common libraries be named all
lower case?

(2) Does the standard mandate this now?

I think that owing to lack of representation of Microsoft C
programmers on the standards bodies, a lack of representation caused
in part by anti-Microsoft and anti-IBM snobbery, this issue was not
faced.

I don't think the original intent of K & R was to make file
identifiers into Sacred Names. I do think that it's an instance of
techno-barbarism and a Negative Dialectic that they have become
sacred. That is, technical progress up until circa 1980 created free
thinking human beings able to communicate civilly (for example in the
old structured walkthrough) *sans peur et sans reproche* giving mere
technicians of the time aristocratic privileges of mutual respect (an
early book describing the rise of Bell Northern Research along the
line of the more famous "Soul of a New Machine" was called "knights of
the new technology".

But under the pressure of the Reagan-Thatcher re-assertion of the
rights of money and property, these same technicians *undt seinem
kinder* found they had willy-nilly to erect a defensive laager to
protect their status much as cities in Germany in the middle ages
needed charters of liberty to protect them against aristocratic
thugs.

At the gates, the guards ask all who would enter how many bits are in
an ASCII code and they slay them if they reply with any number other
than seven.

This is bullshit, because it sacrifices communication and clarity-as-
understanding for membership in a fear-ridden guild whose members,
unlike the guild members of the middle ages, cannot even protect their
jobs.

Thus, stdio.h and other ridiculous (too short for starters) names
become standards in a way that violates our need for elegance. I think
that a younger Kernighan meant there to be many Cs all with different
libraries for different tasks on the model of a later "kernel OS" but
this openness and flexibility was destroyed ... in part by the fact
that not only is entry (or in the case of unemployment, re-entry) to
the laager is controlled not only by shibboleth but also head hunters
who don't know C but are nonetheless delegate to ask if the applicant
or re-applicant knows C.

 

[Walter Banks]

I think that owing to lack of representation of Microsoft C
programmers on the standards bodies, a lack of representation caused
in part by anti-Microsoft and anti-IBM snobbery, this issue was not
faced.

I guess that is why Microsoft hosted two of the WG14
standards meetings within the last few years.

 

[Richard Tobin]

I think that owing to lack of representation of Microsoft C
programmers on the standards bodies, a lack of representation caused
in part by anti-Microsoft and anti-IBM snobbery, this issue was not
faced.

[/QUOTE]

I guess that is why Microsoft hosted two of the WG14
standards meetings within the last few years.

In any case, the idea that Microsoft would be absent from a standards
body becaue of "anti-Microsoft snobbery" is ridiculous. Microsoft's
participation in standardisation is decided entirely on the basis
of whether they consider it to their commercial advantage.

-- Richard

 

[spinoza1111]

In

spinoza1111wrote:



I always give you straight answers.



Note that CTCR2e was published after C89, and advertises that it
covers ANSI C, so I'm taking that as my baseline. (CTCR1e was
published in 1987, before ANSI C was finalised, but the bulk of the
Standard was in place by 1986, and as Schildt claims to be on the
Committee, obviously he has no excuse not to be aware of its
contents.)


No, no, and no - "stdio.h" is not a library, the canonical form is
<stdio.h>, and the Standard does not *require* that header names be
in lower case. It grants explicit permission to ignore case (and to
limit the number of characters before the dot to six!), but does not
impose these permissions as requirements.

Ok, if the Standard does not require that the names be in lower case,
what possible basis could there have been for Seebach to count this as
an error?

From CTCN:

"Page 284
All of the header files are listed in capitals; the standard specifies
them in lower case. It is not required that a C compiler reject all-
caps, but nor is it required that it accept them."

Your claim that the standard "grants explicit permission to ignore
case" is consistent with Seebach's "not required to accept all-caps",
but what's really bothering Seebach, and which he falsely implies is
an error, is Herb's use of upper case.

Herb's use of upper case was NOT A BUG and not in violation of the
standard, yet it was a listed AS AN ERROR in a document which listed
20 "known" errors, this nonerror being included.

His failure is only a failure to pronounce the name of an ear of corn
correctly in a barbaric world: to use a shibboleth.

Had Seebach had his document reviewed properly by McGraw Hill, this
error, which is HIS error and NOT Schildt's, would have been caught.
Had he admitted it, Herb and McGraw Hill may very well have changed
the names to the unix-preferred lower case in the 2nd edition.

But instead, Seebach's unrefereed and dishonest document went viral
and grievously harmed Schildt.

Again: an apology and a withdrawal of the document is in order.

The Standard does, however, say that "The implementation shall provide
unique mappings for sequences consisting of one or more letters (as
defined in $2.2.1) followed by a period (.) and a single letter." The
C89 Standard specifies 15 standard headers, all of which are lower
case. The implementation is required to provide unique mappings to
these headers. A case-sensitive file system can provide this mapping
but is under no obligation to provide the *same* mapping for, say,
<stdio.H>, or <stDio.h>, or <sTdIo.H>.

This is irrevelant, since Herb's platform was not case-sensitive, and
he made no error, since on his platform, the mapping exists. To
include it as an error was a falsehood, and libelous in the twofold
sense of causing harm and meaning to.

The situation has not changed.


Yes, but, as usual, what you think bears no relation to reality. Ralph
Ryan, David Weil, and Mitch Harder, all of Microsoft, were all on the
C89 committee. So were IBM's Shawn Elliott, Larry Breed, and Mel
Goldberg.

They appear to have been about as represented as was Herb, who was on
the C99 committee. It appears to me that both committees were
dominated by greedy non-Microsoft vendors whose main concern was that
the committee members "standardize" an existing mess by pronouncing
dozens of practices "undefined", here the effect of using upper case
file identifiers. Again, I believe that this was done since non-
Microsoft vendors didn't want to change their compilers, having laid
off their competent people.

 

[Ben Bacarisse]

... Firstly, I know of no evidence whatsoever to support the
claim that Herbert Schildt was on the C99 committee.

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n805.htm

I don't know how you define being on a committee, but a membership
list is evidence of some form of being "on the committee".