Re: remove unportable casts and storage allocation tricks from Bison

[Paul Eggert]

> From: Akim Demaille <address@hidden>
> Date: Sun, 05 Jan 2003 14:49:42 +0100

> | 2002-12-12  Paul Eggert  <address@hidden>
> | 
> |     * src/derives.c (derives_compute): Do not subtract NTOKENS from
> |     the pointer DSET returned by malloc; this isn't portable.
> |     Instead, always use DSET[i - NTOKENS] rather than DSET[i].
> |     Similarly for DERIVES.
> 
> What was the problem with this code?  It's been in Bison since its
> inception!

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

> |     * src/derives.c (derives_compute): Do not bother invoking
> |     int_of_rule_number, since rule numbers are integers.
> 
> Yes, but I used this to make sure I had propagated the types
> everywhere: I was changing one typedef to something stupid, say a
> pointer type, and was using the compiler to find the errors.  I would
> love to have incompatible integer types in C, but...
> 
> That's also why there are those foo_as_bar_numbers macros, which are
> now functions.

I think I followed that, but I think you went too far in that
particular case, since you added two numbers without the proper
conversions, and anyway it wasn't clear what the proper conversions
ought to be, and (I am all running off vague memory here) the
conversions that you did use might have caused unnecessary integer
overflow.  It was simpler just to remove the conversion, just for now.

> 
> |     * 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.

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

> |     (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.

Yup, when time permits.