[cfe-dev] Pointers to Overloaded C Functions

[Daniel Dunbar]

On Mon, Jan 4, 2010 at 10:15 AM, Douglas Gregor <dgregor at apple.com> wrote:
>
> On Jan 4, 2010, at 10:13 AM, Eli Friedman wrote:
>
>> On Mon, Jan 4, 2010 at 9:53 AM, George King <gwk.lists at gmail.com>
>> wrote:
>>> I am experimenting with clang's overloaded C functions, and I can't
>>> figure out how to get a pointer to an overloaded function.
>>>
>>> test program:
>>>
>>> #define OL __attribute__((overloadable))
>>>
>>> void OL a(int x) { printf("i: %d\n", x); }
>>> void OL a(float x) { printf("f: %f\n", x); }
>>>
>>> int main(int argc, char** argv)
>>> {
>>>    a(1);
>>>    a(1.0f);
>>>
>>>    void(*a_i_ptr)(int) = a;
>>>    void(*a_f_ptr)(float) = a;
>>>
>>>    return 0;
>>> }
>>>
>>>
>>> compiler output:
>>>
>>>> clang test_ol.c
>>> test_ol.c:25:11: error: incompatible type initializing '<overloaded
>>> function type>', expected
>>>      'void (*)(int)'
>>>    void(*a_i_ptr)(int) = a;
>>>          ^               ~
>>> test_ol.c:26:11: error: incompatible type initializing '<overloaded
>>> function type>', expected
>>>      'void (*)(float)'
>>>    void(*a_f_ptr)(float) = a;
>>>          ^                 ~
>>> 2 diagnostics generated.
>>>
>>>
>>> If I change the name of one of the functions, then it compiles;
>>> clang appears well aware of the syntactic ambiguity. Is there a
>>> more specific syntax to specify which function I'm  referring to?
>>>
>>> Something like "void(*a_i_ptr)(int) = a(int);" makes sense to me,
>>> but I imagine that it's a stretch as far as extending the language
>>> goes.
>>
>> Umm, interesting... I think it's just some missing logic in the code
>> for assignments in C.  I don't think anyone considered that someone
>> might write code like that.
>
> I don't know if we even want to support that kind of code... the
> "overloadable" attribute is narrowly defined to help support certain
> weird C99-isms (*cough* tgmath.h *cough*). We don't really want to
> encourage widespread use, since it is likely to never be portable.

If we really don't want to encourage use, we should find a way to
disable (or at least warn) on the attribute outside of clang specific
headers. Otherwise, it will almost inevitably become a compiler
feature.

It would be nice to do the same thing for at least some __builtin...s,
actually, so that any use outside of clang's private headers triggered
a warning.

 - Daniel

>        - Doug
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>