Re: [Bug-gnulib] linebreak.c proposed patches for size-calculation overflows

[Paul Eggert]

Bruno Haible <address@hidden> writes:

> > I don't think we can easily find out all the variants in this area; it will
> > be a porting hassle with no real payoff.
> 
> Being able to use a macro specified by ISO C 99 is "no real payoff" ??

That depends on whether clients of xsize.h expect it to define
SIZE_MAX.  If they do, then there's some payoff, since client code can
use SIZE_MAX after including xsize.h.  If they don't, then there's no
real payoff; it's just as easy for xsize.h to use "(size_t) -1" --
which has no portability problem -- as it is to use "SIZE_MAX".  (It's
not like this would be unusual; several other gnulib modules already
use "(size_t) -1".)

Unfortunately xsize.h defines SIZE_MAX incompatibly with C99.  In C99,
one can use SIZE_MAX in preprocessor expressions; this isn't true for
xsize.h's SIZE_MAX.  So clients of the current xsize.h can't expect
SIZE_MAX to be completely compatible with C99.

On another subject, I find this code:

      void *p = (!size_overflow_p (size) ? malloc (size) : NULL);

to be hard to read.  I'd rather just write this:

      void *p = malloc (size);

This can be accomplished by having gnulib's malloc wrapper check for a
SIZE_MAX argument, on hosts where we're not sure that malloc(SIZE_MAX)
always fails.  With glibc, malloc(SIZE_MAX) always fails, so no
wrapper would be needed.

Also, I'd prefer prepending an 'x' to the names of the overflow
predicates -- for consistency with the other names defined.  And I'd
omit the trailing '_p' (as I'm not a big fan of Hungarian notation :-).