[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


From: Markus Mauhart
Subject: eval(..)
Date: Fri, 30 Jul 2004 20:49:34 +0200


I'm just exploring huge function eval() in read.c and have some questions:


at line 1038 ...
            unsigned int l = p - variable_buffer;
            unsigned int l2 = p2 - variable_buffer;
            plen = strlen (p2);
            (void) variable_buffer_output (p2+plen,
                                           lb_next, strlen (lb_next)+1);
            p = variable_buffer + l;

... I wondered about the two references to 'p', cause AFAICS 'p' never pointed
into the same array as variable_buffer, hence in C-theory we must not subtract
this two unrelated pointers; but if that doesnt matter in reality but
variable_buffer_output would really reallocate variable_buffer, then the 
p would point to some random position ... the solution comes a few lines later,
with the next reference to 'p':

    wtype = get_next_mword (p2, NULL, &p, &len);

... this one unconditionally overwrites p without reading it, hence the
preceding illegal uses of 'p' may be removed.


At line 851 there comes (comments removed) ...

if (line[0] == '\t')
  p = collapsed;
  while (isblank ((unsigned char)*p))
  if (*p == '\0')
    continue; /* line 858 */
  fatal(fstart, _("commands commence before first target"));

... but before at line 581 there was ...

  p = collapsed;
  while (isspace ((unsigned char)*p))
  if (*p == '\0')

... and AFAICS the content of string collapsed hasnt changed meanwhile
(at least not its potential initial sequence of whitespace).
But then the "continue" at line 858 would never happen, and therefore its
line and the preceding lines starting with "p = collapsed;" could be
replaced with the statement "this line is not empty, see above";
Right ?


parts of the 350-lines block starting at line 877, commented with ...
    /* This line describes some target files.  This is complicated ... */

1st I'm wondering why this block uses the original 'line' and not its
preprocessed version from 'collapsed' [which has all BS EOL converted into
space, and from the single resulting line (there are no un-escaped EOL in
'line') it has removed optional trailing comment]. This block instead 1st
removes trailing comment from line (but only under certain circumstances),
then it collapses some (but not all ?) BS EOL inside line.

I can see two explanations for such:

* either the old 'collapsed' has been changed additionally so that it no more
  really represents the "line" as we want it now.
  But I couldnt find any change except as done by "collapse_continuations" and

* or thist block needs to use both old "collapsed" and "line" separately.
  But AFAICS 'collapsed' is never used in it.

So on 1st look it seems that this block could spare some processing if it
used old preprocessed 'collapsed' instead of again processing 'line'.
Additionally it seems that this block does not enough processing on 'line':
I couldnt find the place where it ignores trailing comments or collapses
BS EOL after unescaped ';'.

So does anyone know why this block needs to use 'line' instead of 'collapsed',
and whether or where does it treat trailing comments and BS EOL after
unescaped ';' ?

And while researching this one I found in "record_target_var(..)" the following:

  v = parse_variable_definition (&p->variable, defn);
  v->value = xstrdup (v->value);
  if (!v)
    error (flocp, _("Malformed pattern-specific variable definition"));

... its 2nd line probably should be its last one.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]