Re: Group static constructors and destructors in specific subsections, take 2

[Dave Korn <dave dot korn dot cygwin at gmail dot com>]

On 12/11/2010 18:52, Ralf Wildenhues wrote:
> * Dave Korn wrote on Fri, Nov 12, 2010 at 12:23:25AM CET:
>> On 11/11/2010 22:04, Dave Korn wrote:
>>
>>>> If this entry should be there, then it should be a @deftypefnx one, and
>>>> without a preceding empty line.
>>> The change is coming from genhooks, autogenerated based on the addition to 
>>> target.def.  It appears that if you add a new hook in target.def, but don't
>>>  add an @hook documentation paragraph in tm.texi.in to match, genhooks.c
>>> emits the @deftype{fn,var} start marker along with the function name and
>>> parameters, but then fails to enter this if clause in emit_documentation():
>>> ... which is where the end directive gets emitted.  Genhooks should
>>> probably fail more gracefully, but I imagine it is an error to add a new
>>> hook to target.def without documenting it in tm.texi.in.  (If this isn't
>>> attempting to enforce policy, then moving the final printf() outside the if
>>> condition should do the trick.)
>>   Actually, it's deliberate:
> 
> It doesn't matter if it's deliberate or not.  A texinfo file must be
> well-formed.  That means, each @deftypefn must end with @end deftypefn,
> without intervening @deftypefn lines.  Between these two, there may be
> zero or more @deftypefnx lines.

  Yes, and if the @hook hunk had not been missing from tm.texi.in, that is
exactly what genhooks would have output.  But the @hook hunk was missing,
which is not allowed when the doc string is "".  This is a simple case of
GIGO: the input to genhooks was invalid, and it ended up generating invalid
texinfo output as a result.


    cheers,
      DaveK