bug-gnulib
[Top][All Lists]
Advanced

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



reply via email to

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