Re: xsize and flexmember

[Paul Eggert]

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.
There's also the theoretical problem that INTMAX_MAX might be greater than
UINTMAX_MAX, but perhaps we needn't worry about that....

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.

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

Yes, good point.