Re: several buglets in CVS m4

[Ralf Wildenhues]

Hi Eric,

* Eric Blake wrote on Fri, Jun 16, 2006 at 03:30:02PM CEST:
> According to Ralf Wildenhues on 6/16/2006 1:33 AM:
> > 
> > 1) The modules/gnu.la library has the global unprefixed symbol `format'.
> > This looks like a bug to me.
> > 
> > 2) modules/m4.la has the global symbol m4_sysval, so has the m4_ prefix
> > but not the m4_LTX_m4_ prefix.
> 
> But you didn't provide a patch for these issues?

Right.  I may look into it, but not at this point.

> > 3) Automake creates build tree directory rules for the targets it writes
> > the rules for (the .dirstamp stuff), but not for manually written rules;
> > this needs to be done for doc/m4.1 (for a VPATH build).  Patch below,
> > written not to depend on the Automake internal detail .dirstamp.
> 
> Thanks for catching that; I don't have easy access to a non-GNU make for
> VPATH testing.

Erm, this happens with GNU make as well.  Just try a new build VPATH
build tree.  I haven't started testing non-GNU make implementations,
except for pmake (which is harmless by some means).

> > 4) GCC 4.0 has dropped the cast-as-lvalue extension, needing a change in 
> > src/stackovf.c.  Patch below.
> 
> But why do we need the cast at all?  Don't all pointers automatically
> promote to void*?

To avoid a warning, casting from const-pointer to non-const void
pointer, I think.

> > 5) GCC 4.1 uncovered a potential bug in reload_frozen_state: with
> > suitable settings M4ERROR may not exit the program but suppress the
> > warning[...]

> Indeed, there's a bigger set of issues here, and it affects 1.4.x as well
> (although I'm less inclined to change status quo on the 1.4.x series).
> GNU Coding Standards state that error messages should be
> 
> program:file:line: message
> 
> But M4ERROR is doing
> 
> file:line: program: Message

Oh, I didn't even notice that...

Cheers,
Ralf