Re: xsize and flexmember

[Marc Nieper-Wißkirchen]

Am Fr., 1. Mai 2020 um 00:20 Uhr schrieb Paul Eggert <address@hidden>:
>
> On 4/30/20 2:01 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?
>
> If n == FLEXSIZEOF (type, member, n) then overflow has not occurred, yes. And 
> in
> that case the function should yield n. (Admittedly this case would be 
> rare....)
>
> > 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;
> > }
>
> This would require including stdint.h to get uintmax_t, which adds a 
> dependency.
> Also, xflexsizeof_xsize_bound shouldn't be a static function since extern 
> inline
> functions can't call static functions, though that should be easy to fix.

We could make it external inline.

> There's also the theoretical problem that INTMAX_MAX might be greater than
> UINTMAX_MAX, but perhaps we needn't worry about that....

Alternatively, we can add a dependency to the xsize module for the
module that exports FLEXSIZEOF_XSIZE so and duplicate the code of
FLEXSIZEOF_XISIZE but do the additions with xsum and friends. The "&"
operator may still be a problem.

> I can see going either way on this. As a macro, FLEXSIZEOF_XSIZE could insist
> that its last argument be free of side effects, and that would be simpler on 
> the
> implementation. It's an annoying restriction, though.

If it is documented, I think this would be okay if not optimal.

>
> > maybe FLEXSIZEOF_XSIZE, which would at least drop the
> > leading "x" as we no error is signaled. :)
>
> Yes, good point.
>