> On Aug 26, 2024, at 15:46, Bill Wendling <isanb...@gmail.com> wrote: > > On Wed, Aug 21, 2024 at 8:43 AM Martin Uecker <uec...@tugraz.at> wrote: >> >> Am Mittwoch, dem 21.08.2024 um 15:24 +0000 schrieb Qing Zhao: >>>> >>>> But if we changed it to return a void pointer, we could make this >>>> a compile-time check: >>>> >>>> auto ret = __builtin_get_counted_by(__p->FAM); >>>> >>>> _Generic(ret, void*: (void)0, default: *ret = COUNT); >>> >>> Is there any benefit to return a void pointer than a SIZE_T pointer for >>> the NULL pointer? >> >> Yes! You can test with _Generic (or __builtin_types_compatible_p) >> at compile-time based on the type whether you can set *ret to COUNT >> or not as in the example above. >> >> So it is not a weird run-time test which needs to be optimized >> away. >> > Using a '_Generic' moves so much of the work onto the programmer that > it would be far easier, and cleaner, for them simply to specify the > 'counter' field in the macro and be done with it. Something like: > > #define alloc(PTR, COUNT, FAM, COUNTER) > > If the FAM doesn't have a 'counted_by' field: > > #define alloc(PTR, COUNT, FAM) > > (It would use VAR_ARGS of course). Why not simply have the compiler > automatically adjust the return type?
What do you mean by “have the compiler automatically adjust the return type”? From my current GCC implementation, if there is counted_by object associated with the flexible array member, then the returned pointer points to the counted_by object (which has its own original type), compiler does not need to _adjust_ the returned type. So, what do you mean by _adjust_? Qing > It's perfectly capable of Doing > the Right Thing(tm). Otherwise, this builtin becomes even less > desirable to use than it currently is.
