bug-gnulib
[Top][All Lists]
Advanced

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

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


From: Bruno Haible
Subject: Re: [Bug-gnulib] linebreak.c proposed patches for size-calculation overflows
Date: Thu, 6 Nov 2003 15:56:12 +0100
User-agent: KMail/1.5

Paul Eggert wrote:
> 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.

I could make up a SIZE_MAX definition that will work in preprocessor
expressions, using yet another autoconf macro. But here I'm too lazy.
I'm satisfied with SIZE_MAX as being usable inside functions.

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

When doing this, I fear to mix different unrelated things. Actually
xsize.h defines a new abstract type, that happens to be encoded in a
size_t. Therefore I'd prefer to name this function/macro xsize_malloc
or so, differently than the ANSI C 'malloc',

The majority of the allocations in gnulib is done through xmalloc,
which gnulib "owns", so here I don't mind whether xmalloc does the
test against SIZE_MAX or not.

> Also, I'd prefer prepending an 'x' to the names of the overflow
> predicates -- for consistency with the other names defined.

'x' means 'checking' in this contest. The predicates are not in the
same category: they don't perform "an operation with overflow checking".

> And I'd
> omit the trailing '_p' (as I'm not a big fan of Hungarian notation :-).

This isn't hungarian notation, it's the common notation in gnulib
(started with obstack) for predicates. Due to the need to distinguish
constructive/destructive operations and tests, we got several notations:

    empty! and empty?                (Scheme conventions)
    empty and emptyp / empty-p       (Lisp conventions)
    empty and isEmpty                (Java conventions)

In GCC, Emacs and obstack the Lisp notation with "_p" is used. Why should
I start using a different notation here?

Bruno





reply via email to

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