Re: [Tinycc-devel] Segmentation fault compiling jslong.c

[Rob Landley]

On Friday 21 September 2007 8:41:58 am Gregg Reynolds wrote:
> > Seriously.  It is a reference book on C written to complement K&R and
> > has been used as such since the first edition in the eighties (predating
> > the standard).
>
> Rob, you'd probably find it well worth the money.  In particular it
> discusses the differences between the different versions of C, so if
> you want to support pre-C99 code you'll probably find it
> indispensable.

I have a draft of the spec itself, in html format.

I build some code, it breaks, I figure out why.  (Or somebody else reports to 
me that _they_ build some code, it breaks, I reproduce it and figure out 
why.)

When I run out of stuff to do on that front, I'll let you know.

> > > don't remember ever hearing anyone refer to "projection", so when you
> > > refer to it as a vital theoretical concept and imply that this name is
> > > commonly used for it, I tend to stop paying attention to the rest of
> > > the paragraph...
>
> Always a good reading strategy.

Using the absence of something over a 17 year period, and a corresponding lack 
of recent change in the subject matter, to judge that it can't possibly be as 
important as they're attempting to imply?  Yeah, I'd consider that a viable 
classification strategy.

> Why risk learning something when you've got real work to do?  ;)

Why do you assume you have something to teach me?

"What is this guy blathering about?" != "I cannot comprehend his brilliance."

FYI.

The long version:

I always have this reaction to ungrounded theory.  It comes from three 
attempts at a master's in computer science running into ivory tower academics 
who are trying to do things like teach their 30 years of research 
into "parallel algorithms", which turnsout not to have anything to do with 
SMP but a theoretical machine with an infinite number of processors advancing 
their clocks in lockstep and able to read and write from memory 
simultaneously without any propogation delay, so you can avoid ever having to 
lock by counting the number of instructions and timing everything carefully.  
The fact such a machine is physically impossible to build in a universe where 
the speed of light is a limiting factor in signal popagation never entered 
into it, they were still teaching this in 1996.

Or the guy who was trying to mathematically prove the correctness of a 
specific implementation of the Java 1.0 compiler (by porting it to a Lisp 
dialect and then having a team of multiple people spend five years on it, by 
which time Java 1.2 was out, I'd seen several systems die in the field due to 
bad memory or a dodgy power supply in ways that presented as software 
problems, I'd had to abandon a Java project because Java 1.0 didn't have any 
way to truncate an existing file which had _nothing_ to do with the 
assumptions matching the implementation...)

I am an engineer, not a mathematician, and a pragmatist rather than an 
idealist.  "The difference between theory and practice is that in theory 
there is no difference, in practice there is."  I've developed an allergy to 
ivory towers for this reason: go too deep into the theory without grounding 
it in something useful and it just stops being interesting.  I don't care 
what pure theory says because I've seen reality disagree too much.

I dig into complexity to look for the simple behind it, or else to find a 
nasty corner case I can't avoid dealing with.  I'm only interested in a 
complex solution if there's some concrete _advantage_ over a simple solution 
that outweighs the cost of the complexity, and that extends to the analytical 
models used in the design.

The short version:

Start climbing an ivory tower, I stop listening.

> Seriously, I didn't mean to sound pedantic.  I should have added the
> caveat that I'm trying to find clear language for expressing C
> semantics,

*shrug*  I'm weird, I'll admit it.  You managed to hit some of my hot buttons 
by accident.

As for "trying to find clear language", neither the c89 or c99 specs, nor the 
C FAQ resulting from literally decades of discussion on comp.lang.c, have 
managed to do this already?

http://www.faqs.org/faqs/C-faq/faq/

> I think it's possible to do this, if
> one is willing to jettison the traditional metalanguage used to
> discuss C, but it's a work in progress and not to everyone's taste.
> If the result sounds like a lecture, well, I'll have to be more
> careful.

There is a difference between what I'm capable of understanding, and what I 
consider important.

I did get an english minor (Rutgers, '95).  I have in fact _had_ courses on 
etymology and the history of the english language and so on.  The result is 
that I'm waiting for "gonna" to become an official contraction of "going to", 
am happy that we're now allowed to boldly split infinitives that no man hath 
split before (thanks be to star trek, yea verily alelujiah amen and 
gesundheit), and even voluntarily use "ain't" from time to time.  Gotta know 
the rules before you can break 'em. :)

Go back far enough and any language is entirely made up, it's just a tool for 
people to tell stuff to other people.  There's no such thing as a "correct" 
word; when enough people start equating "hacker" with "computer criminal" the 
dictionary changes its definition and the old one becomes archaic.  The 
word "terrific" used to be close to "terrifying".  The "lingua franca" is now 
English.  Words _ever_ only have "commonly accepted" meanings, no matter what 
the academie francaise says.  (I don't consider it a coincidence that 
the "lingua franca" is now english when the french have an institute to tell 
you what you can't say, and over here random civilians can get a made up word 
like "blogosphere" internationally accepted in about 3 years.)

Wandering back on topic, people who care about formal mathematical models use 
lexx and yacc.  People who want to turn source code into object code in a 
fast and simple way with minimal external dependencies hand code recursive 
descent parsers in ways that make theoretical mathematicians' skin crawl.  
Which kind of project is tcc?

Back in college, I stopped reading about Backus-Naur form when I found out 
it's not executable.  GCC had all this BNR stuff, but it never ran a 
preprocessor on BNR source to generate actual code.  For me, it went 
from "useful tool" to "waste of time" with that one fact.  Because something 
like that _could_ be executable, but the kind of people who use it apparently 
don't think that's important.  This was my first big "Shut up and show me the 
code!" moment.  (I've had to learn it since because some stuff is _only_ 
documented in it, but I consider that a deficiency of the documentation.)

Rob
-- 
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.