[PATCH v2] New mechanism for declaring const-covariant string functions.
Florian Weimer
fweimer@redhat.com
Wed Nov 23 13:29:00 GMT 2016
On 11/23/2016 02:06 PM, Zack Weinberg wrote:
> On Tue, Nov 22, 2016 at 4:05 AM, Florian Weimer <fweimer@redhat.com> wrote:
>> On 11/21/2016 06:46 PM, Zack Weinberg wrote:
>>> diff --git a/string/bits/const-covariance.h
>>> b/string/bits/const-covariance.h
>>> +#define __CC_VA_NARGS(...) __CC_VA_NARGS_(__VA_ARGS__, __CC_RSEQ)
>>> +#define __CC_VA_NARGS_(...) __CC_VA_NARGS__(__VA_ARGS__)
>>> +#define __CC_VA_NARGS__(_1, _2, _3, _4, _5, _6, _7, _8, N, ...) N
>>> +#define __CC_RSEQ 8, 7, 6, 5, 4, 3, 2, 1
>>
>> It's not clear to me what ensures that variadic macros are available at this
>> point. <bits/const-covariance.h> seems to be included unconditionally, not
>> just for GNU or C++11. I don't think you can use variadic macros for this.
>
> This is a good point. I had been blithely assuming that all supported
> compilers provide variadic macros as an extension even in C89 mode,
> but maybe I shouldn't do that.
>
> To avoid variadic macros we would need to encode the number of
> arguments in the macro name, e.g.
>
> __CONST_COV_PROTO_2 (strchr, char *, __s, int, __c);
> __CONST_COV_PROTO_3 (memchr, void *, __s, int, __c, size_t, __n);
>
> Do you think we could live with that? I won't have time to rework the
> patch till the weekend.
I think the diagnostics issue is the show-stopper here. This looks
increasingly like an application of Joseph's idea of generated installed
headers.
Thanks,
Florian
More information about the Libc-alpha
mailing list