Yes, the biggest problem with #includes is the namespace cross contamination they can cause. I once tracked a build problem down to someone #defining usleep(time) to 'sleep(time/1000)' (or something similar). Problem was, usleep was included later, so the definition of the real usleep got replaced with gibberish that did math inside a function declaration.

I'm really looking forward to maintaining your code.

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.