Re: remove unportable casts and storage allocation tricks from Bison

[Akim Demaille]

 >> What was the problem with this code?  It's been in Bison since its
 >> inception!

 Paul> Some architectures don't let you compute pointers to places that
 Paul> aren't really storage.  (You are allowed to compute a pointer to one
 Paul> just past the end of an array, but that's the only exception.)
 Paul> Apparently Bison hasn't been run on such architectures (maybe those
 Paul> guys are all using byacc?) but I've heard that they do exist.

I've heard that too, but saw no evidence of this either.  That found
that the code was cutter and probably faster, but OK.


[Integer types]

 Paul> I think I followed that, but I think you went too far in that
 Paul> particular case, since you added two numbers without the proper
 Paul> conversions, and anyway it wasn't clear what the proper conversions
 Paul> ought to be, 

Agreed.

 Paul> and (I am all running off vague memory here) the conversions
 Paul> that you did use might have caused unnecessary integer
 Paul> overflow.  It was simpler just to remove the conversion, just
 Paul> for now.

OK.


 >> |   * src/state.c (TRANSITIONS_ALLOC, ERRS_ALLOC, REDUCTIONS_ALLOC,
 >> |   STATE_ALLOC): Remove.
 >> |   (transitions_new, errs_new, reductions_new, state_new): Use malloc
 >> |   rather than calloc, and use offsetof to avoid allocating slightly
 >> |   too much storage.
 >> 
 >> I don't understand this latter statement.  I guess it is related to
 >> some form of padding I don't imagine, but I fail to understand why
 >> using offset here is a better solution.

 Paul> Yes, it's a padding issue.  offsetof can yield a smaller number than
 Paul> the non-offsetof solution, and this can save some space.  The
 Paul> non-offsetof solution will pad the structure according to the
 Paul> strictest alignment of any structure member, whereas the offsetof
 Paul> solution will pad only to the alignment required for the varying-size
 Paul> member.

Huh.  Now I think I see what you mean: padding *after* the array
(pointer) in the struct?

 >> |   (CALLOC, MALLOC, REALLOC): New macros.
 >> |   All uses of XCALLOC, XMALLOC, and XREALLOC changed to use these
 >> |   new macros.
 >> 
 >> If you think these macros are better, then they should probably make
 >> their way into xalloc.h, and therefore the gnulib.

 Paul> Yup, when time permits.

:) :)