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

[Gregg Reynolds]

On 9/20/07, Rob Landley <address@hidden> wrote:
> > "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

For c99, yes, if you want backwards compatibility it's rather more
complicated.  See Harbison and Steele for four different ways of
dealing with it.

> something you're going to use (and that the linker has be able to find), but
> it doesn't instantiate it.

Right, the key point being linker visibility.  Near as I can see
that's the only distinction between static and extern for file-scope
names.
>
> > 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

I mean "extern" tells the compiler "this name is available outside its
scope of declaration"; i.e., I'm registering this name for local use,
but its meaning is somewhere outside of this scope. You can declare
externs inside of blocks:

 {
   extern int e;
   ...
 }
  e = 3;  /* example from Harbison and Steele */

Hideous but legal (I think).  For file-scope variables extern means
"available outside of this translation unit", which essentially means
"register this name in the global lexicon" and worry about its
definition later.  I guess "projection" might not be entirely
accurate, but it gets at the basic idea.

> 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.

More than that, it says "register this name" so I can use it in this
file without having defined it.
>
> ("Value projection operators"?  Insert raised eyebrows.)

Structs are opaque; you can only get access to member values by
projecting them into the containing scope.  An expression like s.foo
projects the value member foo beyond the scope of its declaration into
the scope of the expression.  If i is extern, use of i is like
"_globals->i"

Pedantic maybe, but a useful unifying abstraction that brings scoping
to the fore and dovetails nicely with the reading of "extern" as a
projecting op.

>
> > 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

I read that at first glance as "to start cats".  I think I like that better. ;)

> means is "doesn't move", same root as stasis.

Mmm, more like "stands", which isn't quite the same.  In any case, it
certainly doesn't mean "local, non-exported", which is essential to
its C semantics (actually, it has two independent context-dependent
meanings in c, which is even worse).

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

Lawyers?  They're the only people I can think of with a more
persistently antagonistic relationship with the English language.  The
Worst Standard Ever is ISO SGML, written by a lawyer-cum-software
developer.  An indecipherable nightmare.

-g