bug-bison
[Top][All Lists]
Advanced

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

bison-20001221


From: Hans Aberg
Subject: bison-20001221
Date: Sat, 23 Dec 2000 22:49:14 +0100

I picked down ftp://alpha.gnu.org/gnu/cvs/bison-20001221.tgz. Some bugs:

- The file version.texi, needed by bison.texinfo is not in the distribution.

- On a number of places there is
  include <config.h>
It should be
  include "config.h"

- Files "files.c" and "complain.c" reads the macro definition differently:
"files.c" somehow gets it from "error.h", I think, whereas "complain.c"
does not read it at all. So I had to throw in
#ifndef __attribute__
#define __attribute__(x)
#endif
into the file "complain.h" in order to be sure is always defined (which
should be empty on my system).

- File "files.c" uses stpcpy() and strndup() which is not in the C standard
(and I have no other mentioning of it). So I put in definitions (hope it is
correct):
char* strndup(const char* s, size_t n);
char* stpcpy(char* s1, const char* s2);

char* strndup(const char* s, size_t n) {
  char* ret;
  size_t len = strlen(s);
  if (n >= len)
    return strcpy(xmalloc(len + 1), s);
  ret = strncpy(xmalloc(n + 1), s, n);
  ret[n] = '\0';
  return ret;
}

char* stpcpy(char* s1, const char* s2) {
  strcpy(s1, s2);
  return s1 + strlen(s1);
}

  - compute_base_names() uses strndup() which is not in the C standard, and
for which I have found no reference; it also uses stpcpy().


- File "xstrdup.c", "xmalloc.c", and others, contains platform specific
seemingly unneeded
  #include <sys/types.h>
Also, no prototype
  char *xstrdup (const char *string);

- In files "output.c", output_headers(), and "print.c", print_grammar(), I
got problems with the fact that pre-MacOS X only allows stack allocations
<= 32 kB, here exceeded by the "obstack_..." macros. This just something
platform specific of an old OS, but I think in general, it is wise to not
allocate more on the stack than needed. (For example, each obstack_fgrow1
asks for a stack allocation of 4 kB, whereas in output_headers() the actual
allocation needed for each obstack_fgrow1 is less than 64 B.)
  - I got around the problem by changing the obstack_fgrow1 macro
containing a static array:
  static char buf[4096];
Not pure anymore, but it does not make any difference in my port.
  - Perhaps the obstack should be made into FILE* objects. I didn't see the
growth policy, but if one doubles the stack size whenever it becomes short,
recopying should only be of linear order (2n, if n is the number of
characters allocated).

- There seems to be no file "config.hin" in the distribution, which means
on platforms without "make" the package cannot be used.

- Files "quote.c", "quote_arg.c" includes platform specific <sys/types.h>.
Unnecessary if "quotearg.h" includes <size_t.h>. Also,
  #include <quotearg.h>
  #include <quote.h>
only works if one puts the stuff in the library; not if one takes down
Bison and compiles it directly;
  #include "quotearg.h"
  #include "quote.h"
is safer.

- File "quote_arg.c", "else" clause of "#if HAVE_MBRTOWC": macro "iswprint"
is already in the C-standard, so redefining it here causes an error.

- File "main.c", main() does not have a return value -- produces a warning
from the compiler.

- File "bison.simple",
  int
  yyparse (YYPARSE_PARAM_ARG)
     YYPARSE_PARAM_DECL
does not have a prototype -- produces a compiler warning for example when
compiling under C++.

- The new dynamically computed #line directives are great. -- The filename,
however show up with a full pathname. Perhaps some may want that, but
suppose the sources are distributed to another computer with another
filepath -- then that is broken. So I suggest instead if the single "char*
skeleton", which currently full path-name, using two "skeleton_name" and
"skeleton_path"; then one can use "skeleton_name" in the #line directives.
  - I realize when I write this that it probably happens because I tweaked
"skeleton_find" to output the full pathname. I therefore tweaked it back in
output_parser().

  Seasons Greetings,

  Hans Aberg





reply via email to

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