Re: %destructor feedback

[Joel E. Denny]

On Wed, 7 Dec 2005, Paul Eggert wrote:

> > > > Would (&(e)-1) solve that?
> > >
> > > No, because that's an invalid expression: it normally has undefined
> > > behavior, and 'lint' is within its rights to warn about it.
> >
> > Invalid seems like a strong word. You mean that some lint
> > implementations warn about pointer arithmetic on locals and params?
>
> I meant that the expression causes the code to fail to conform to the
> C standard.  The C Standard prohibits a program from subtracting 1
> from a pointer to the start of an object.

I had no idea the C standard made such restrictions on what computations 
you perform with memory addresses.  So the following is invalid C?

  #include <stdio.h>
  int main() {
    int x;
    printf( "%p\n", (void*)(&x-1) );
    return 0;
  }

I can understand that *dereferencing* a pointer after subtraction might be 
dangerous... (unless you're writing platform-specific code and, in the 
case of autos, know your way around the stack).  But we're not 
dereferencing.

> Not only might some lint
> implementations warn about it, but (worse) some uses of the parser
> might crash.

Why would it crash?

Here's another variation on the static global theme that would avoid the 
boolean and subtraction if that's really what you're concerned about:

  static void* yyunused;
  #define YYUSE(e) yyunused = (void*)&(e)

And then within yyparse (or wherever you like):

  YYUSE (yyunused);

> > > Why can't we simply rewrite the code so that it doesn't declare
> > > unused variables?
> >
> > Is that computable in general?
>
> Not with the current architecture, no.  Not enough information is
> available.  We'd have to change the design slightly.

I agree that such a surgical solution would ultimately be better than the 
band-aid approach we've been taking.

> > perhaps the static global would be a reasonable temporary
> > solution...
>
> I'd rather have something simpler.  The static global is asking for
> trouble.

As Frank pointed out, it seems that any trick we come up for fooling lint 
is asking for trouble.  That's the YYUSE track record.  Unless the surgery 
you've proposed is coming soon, it seems that we need a band-aid that will 
at least stop the bleeding we've actually *seen* so far.  My static global 
does that, and the complaints against it seem mostly hypothetical.

Is the static global variable itself presenting a real problem?  Or is it 
mainly the boolean logic and pointer arithmetic you're opposed to?

> It'd be better just to tell people to not use 'lint'.

That would certainly let me pass my structs.

Joel