Am Fr., 1. Mai 2020 um 00:20 Uhr schrieb Paul Eggert <[email protected]>: > > 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. >
