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

[Rob Landley]

On Thursday 20 September 2007 7:05:20 pm Gregg Reynolds wrote:
> On 9/20/07, Rob Landley <address@hidden> wrote:
> > > Vars with no explicit storage
> > > class default to extern, which implies static.  (5th ed., 4.6.1)
> >
> > extern implies static?
> >
> > Hang on, so if I say "extern int thingy;" in a header, and declare a
> > global "int thingy;" in a .c file, I can't use that "thingy" in another
> > .c file that #includes that header?
> >
> > I'm fairly certain that's not the case.  I think you have to say "static"
> > if you want something to be, you know, static.
> >
> > However, I thought static and extern were diametrically opposed.  We may
> > be talking about something different here...
>
> My bad, I've been slogging through the c99 draft, H&S, K&P for the
> past few days and trying to translate it into English, and forgot to
> disambiguate "static"  The c metalanguage is what is commonly referred
> to as "an unholy mess" (static is not the opposite of dynamic, const
> is not the opposite of volatile, lvalues are expressions, not values,
> "typedef" is a storage class specifier, etc. etc).  When you start
> looking closely at it it's kind of amazing the language was
> successful.  Must have been a case of "do as I do, not as I say".

The language predated the standard by 15 years. :)

The first Unix kernel written in C was around 1972.  The first C standard was 
C89, in 1989.  The C89 standards body was there to document, not legislate.  
That's why they came up with a successful standard, because they didn't come 
up with the _language_.

Denis Ritchie's home page has a lot of good early C stuff, including a manual 
from 1975 that's pretty recognizable to modern users:
http://cm.bell-labs.com/cm/cs/who/dmr/cman.pdf

But the best thing has to be "The Development of the C programming language" 
from the second History of Programming Languages conference:
http://cm.bell-labs.com/cm/cs/who/dmr/chist.html

(The transcript of his talk is also great, but then I'm a computer 
historian. :)

> Static extent (or is it duration? and why can't we stick to one
> metaphor?) and "linkage" (=scope? visibility? huh?) seem to be
> distinct; the "static" keyword means static extent + internal linkage
> (name not exported to linker; I think that means "local scope");
> "extern" means static extent, name exported to linker.  At least I
> think that's the idea.

I tend to use the standard as a tiebreaker, and otherwise use 17 years of 
programming in C as a start for what should probably work, and notice what 
code breaks when I try to compile it...

> > > The
> > > c99 draft says "All the expressions in an initializer for an object
> > > that has static storage duration shall be constant expressions or
> > > string literals".  (6.7.8, constraint 4).
> >
> > So static storage duration != static keyword applied to a global,
> > limiting its scope to the current file?
>
> Bingo.  A conflation of storage duration and scoping, all rolled into
> one unreliable name.  My tentative translation into English:

My brain hurts, but ok.

> "static" =>  eternal life + local scope (block, file, etc.)
> "extern" => eternal life + proselytizing (projection to containing
> scope, either file/TU or global)

The local scope is inherent in the {}, static overrides the lifespan of that.  
Static outside of any {} controls scope rather than lifespan (invisible 
outside of this file.)  If you don't say either, it's still a global variable 
and on the heap rather than the stack.

"extern" means "this is a declaration, but not a definition".  It describes 
something you're going to use (and that the linker has be able to find), but 
it doesn't instantiate it.

I have no idea what language the standard wraps that up in.  Probalbly 
incomprehensible.

> by which I mean "extern" is like a name-projection operator (in
> contrast to value-projection operators . and ->); it projects a name
> into the containing scope,

Nope, it can't.  If the compiler hasn't encountered the "extern" thing yet, 
then it can't know about it.  So it's either in the current .c file or it's 
in a .h file included from that .c file.  "extern" just says "don't 
instantiate this again, there's already one of these" so each .c file doesn't 
duplicate it when you #include the .h file.

("Value projection operators"?  Insert raised eyebrows.)

> which may be the file, er, translation 
> unit, when "extern" is used in block scope.  "Static" is of course
> utterly misused in c, since it basically means const (in English, I
> mean).  Ugh.

It's a type of electricity you use to startle cats.  And what it actually 
means is "doesn't move", same root as stasis.

> > Who named these?
>
> That would be software developers.  ;)_

I doubt it.

> -gregg

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