Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Most C libraries already implement those as both functions and macros. The macro definition usually shadows the function definition, but you can access the function version if you want, e.g. in glibc, getc() will call the macro, while (getc)() will call the function. The macro is just a wrapper for a function anyway in glibc (the internal _IO_getc), so there's no real reason to retain it except for historical reasons. If macros were eliminated in user code, you'd just use the function versions. I think having them as macros at all is an efficiency hack dating back to the days when compilers didn't do function inlining.


> but you can access the function version if you want, e.g. in glibc, getc() will call the macro, while (getc)() will call the function.

Are you sure about this?


Yes (the macro must be define as

     #define getc(stream) ...
of course, but that's the only legal definition anyway).

("Free-standing implementations" like kernels have a lot of freedom to muck with the standard library. But that's not really relevant.)


Ah okay, I understand what you meant now. One thing however - if it is a macro, couldn't it just be:

  #define getc fgetc_or_similar
At least C89/90 only mentions that if it is a macro, it may evaluate arguments more than once (but then it may not, as in the above case).


Yes and no. Yes, that is a valid #define; but the following program must work:

    #include <stdio.h>
    #undef getc
    int main(void) {
        getc(stdin);
        return 0;
    }
so it cannot be implemented as only a macro.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: