Re: xsize and flexmember

[Marc Nieper-Wißkirchen]

Am Do., 30. Apr. 2020 um 22:49 Uhr schrieb Paul Eggert <address@hidden>:
>
> On 4/29/20 11:39 PM, Marc Nieper-Wißkirchen wrote:
>
> >> #define XFLEXSIZEOF_XSIZE(type, member, n) \
> >>   (((n) <= FLEXSIZEOF (type, member, n) \
> >>     && FLEXSIZEOF (type, member, n) <= (size_t) -1) \
> >>    ? (size_t) FLEXSIZEOF (type, member, n) : (size_t) -1)

Why do you write "(n) <= FLEXSIZEOF (type, member, n)" and not "n <
FLEXSIZEOF (type, member, n)"? In case MEMBER is the first element of
TYPE, this would not indicate an overflow, would it?

> >>
> >> A couple of problems with this approach:
> >>
> >>   * It evaluates N more than once.
> >
> > Couldn't this be solved by calling a static function that would be
> > subject to be inlined?
>
> I don't offhand see how to get that to work if n exceeds SIZE_MAX.

My idea was:

#define XFLEXSIZEOF_XSIZE(type, member, n) xflexsizeof_xsize_bound(
FLEXSIZEOF (type, member, n), n)
static _GL_INLINE size_t xflexsizeof_xsize_bound (umaxint_t m, size_t n)
{
  if (n < m && m <= (size_t) -1)
    return m;
  else
    return (size_t) -1;
}

>
> > Why would you prefer the (longer) name XFLEXSIZEOF_XSIZE vs XFLEXSIZEOF?
>
> It's specialized for size_t computations, and is not in general suitable for
> ptrdiff_t or other types. Also, elsewhere in Gnulib a leading "x" means the
> function signals an error if overflow occurs, and that's not what's happening
> here. I realize we have dueling conventions here, but would prefer that
> saturated size_t arithmetic have a longer prefix or suffix than just "x".

I understand. So maybe FLEXSIZEOF_XSIZE, which would at least drop the
leading "x" as we no error is signaled. :)