[Top][All Lists]
[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
- Re: [Bug-gnulib] linebreak.c proposed patches for size-calculation overflows, Bruno Haible, 2003/11/03
- Re: [Bug-gnulib] linebreak.c proposed patches for size-calculation overflows, Paul Eggert, 2003/11/03
- Re: [Bug-gnulib] linebreak.c proposed patches for size-calculation overflows, Bruno Haible, 2003/11/04
- Re: [Bug-gnulib] linebreak.c proposed patches for size-calculation overflows, Paul Eggert, 2003/11/04
- Re: [Bug-gnulib] linebreak.c proposed patches for size-calculation overflows, Bruno Haible, 2003/11/05
- Re: [Bug-gnulib] linebreak.c proposed patches for size-calculation overflows, Paul Eggert, 2003/11/05
- Re: [Bug-gnulib] linebreak.c proposed patches for size-calculation overflows,
Bruno Haible <=
- Re: [Bug-gnulib] linebreak.c proposed patches for size-calculation overflows, Paul Eggert, 2003/11/06
- Re: [Bug-gnulib] linebreak.c proposed patches for size-calculation overflows, Bruno Haible, 2003/11/10
- Re: [Bug-gnulib] linebreak.c proposed patches for size-calculation overflows, Paul Eggert, 2003/11/10
- [Bug-gnulib] Re: linebreak.c proposed patches for size-calculation overflows, Simon Josefsson, 2003/11/19
- [Bug-gnulib] Re: linebreak.c proposed patches for size-calculation overflows, Paul Eggert, 2003/11/19
- Re: [Bug-gnulib] Re: linebreak.c proposed patches for size-calculation overflows, Bruno Haible, 2003/11/19
- Re: [Bug-gnulib] Re: linebreak.c proposed patches for size-calculation overflows, Paul Eggert, 2003/11/19
- [Bug-gnulib] Re: linebreak.c proposed patches for size-calculation overflows, Simon Josefsson, 2003/11/19
- [Bug-gnulib] Re: linebreak.c proposed patches for size-calculation overflows, Simon Josefsson, 2003/11/19
- Re: [Bug-gnulib] Re: linebreak.c proposed patches for size-calculation overflows, James Youngman, 2003/11/19