[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: xsize and flexmember
From: |
Paul Eggert |
Subject: |
Re: xsize and flexmember |
Date: |
Fri, 1 May 2020 13:51:45 -0700 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 |
On 5/1/20 2:20 AM, Marc Nieper-Wißkirchen wrote:
> I think that size_t calculations are still the most important ones.
In other apps I've found many other integer types where overflow is important,
including ptrdiff_t, int, long, and intmax_t. ptrdiff_t is the big one, as its
use is supplanting size_t in some GNU apps (for the same reason GNU malloc
rejects sizes larger than PTRDIFF_MAX).
So I've typically used intprops.h instead of the xsize functions, even for
size_t. intprops.h has the downside of requiring an overflow check after each
arithmetic operation, but in practice that's often not much of a downside. The
existing FLEXSIZEOF macro is like the intprops.h macros, in requiring an
overflow check on use.
One possible way to address the size_t/ptrdiff_t issue would be to have a macro
like the following instead:
/* Like FLEXSIZEOF (TYPE, MEMBER, N) except yield at most MAX, and
N and MAX might be evaluated more than once. */
#define FLEXSIZEOF_MAX(type, member, n, max) \
(((n) <= FLEXSIZEOF (type, member, n) \
&& FLEXSIZEOF (type, member, n) <= (max)) \
? FLEXSIZEOF (type, member, n) : (max))
This way, you could use FLEXSIZEOF_MAX (struct foo, m, n, PTRDIFF_MAX) if you
wanted to treat PTRDIFF_MAX as an overflow signal.