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.
