Re: (security-related) patch to ALLOC macros to prevent integer overflow bugs

On Thu, 4 May 2006, Dominique Brezinski wrote:

> While fixing the integer overflow in rb_ary_fill(), it occurred to me
> it would be better to fix the *ALLOC* macros in ruby.h. The patch is
        [...]
> --- ruby.h.org  Wed Oct 26 00:05:58 2005
> +++ ruby.h      Thu May  4 00:03:36 2006
> @@ -459,11 +459,11 @@
> #define OBJ_FROZEN(x) FL_TEST((x), FL_FREEZE)
> #define OBJ_FREEZE(x) FL_SET((x), FL_FREEZE)
> 
> -#define ALLOC_N(type,n) (type*)xmalloc(sizeof(type)*(n))
> +#define ALLOC_N(type,n) (sizeof(type)*(n)) / sizeof(type) == (n) ?
> (type*)xmalloc(sizeof(type)*(n)) : NULL
>  #define ALLOC(type) (type*)xmalloc(sizeof(type))

 (lines got folded in this quote)
> 
> Humbly,
> Dom

My concerns about this patch probably won't happen, but lest they
have value:  I seem to recall from my reading of "The Practice of
Programming" by Kernighan and Pike that macros where the arguments
are used more than once are to be avoided in case they should be
passed something with side effects.  In this case, suppose ALLOC
were invoked as: 
  ALLOC(int, n++);
then n would be incremented 2 or 3 times.  I thimk a similar point is
made in Programming Pearls.  Is there some reason that ALLOC cannot be
a function?  It would be inlined in most cases by modern compilers.
i think both those texts suggest using functions instead.
> 
Hoping this isn't pointless noise...
        Hugh