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

[Rob Landley]

On Thursday 20 September 2007 9:35:05 pm Gregg Reynolds wrote:
> 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.

You've mentioned Harbison and Steele more than once, but otherwise I've never 
heard of them.  And what I was describing above wsa the way Turbo/Borland C, 
IBM VisualAge, and gcc, have handled c.  (And I think Watcom, too, but I only 
used that as an x86->ppc cross compiler cica 1995, which was funky.)

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

*shrug*

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

Never seen that, never done that, and I'd expect the "extern" to go away at 
the ending curly bracket so if you don't have either a declaration or 
definition of e outside of it I'd expect the e=3 after the curly bracket to 
complain about an unknown symbol.  (Although if there's nested curly brackets 
it _might_ be a way of temporarily referring to a global that's hidden by a 
local, but this is too ugly for words...

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

My problem is you're leaning too hard on a very specific vocabulary.  As I 
said, I've been programming in C for 17 years and in that time I honestly 
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...

*shrug*  Could just be that I've never implemented a compiler, I just debug 
stuff...

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

That would be the "there's already one of these", yes.  Otherwise there's no 
point in bothering to write the extern statement, is there?

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

I know how to use a struct, thanks.  My raised eyebrows are about inventing 
terminology for something obvious.  (I just googled for "value projection 
operator" and the first page neither had those in order nor mentioned C.)

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

I know how to dereference a struct to access its contents.  Honestly I do.

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

*shrug*  My last etymology course was in 1987, I'm not interested in arguing 
with you.

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

No, the bit about startling cats was the part that was essential to its C 
semantics.

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