Đoàn Trần Công Danh <congdanhqx@gmail.com> writes: > > Yes, inline function are always better than macro. > I feel embarassed that I couldn't think about that earlier. > > Here is a revised patch: This version still has some issues on a glibc system. ,---- | In file included from notmuch-client.h:31, | from debugger.c:21: | ./compat/compat.h: In function ‘notmuch_canonicalize_file_name’: | ./compat/compat.h:44:9: warning: implicit declaration of function ‘canonicalize_file_name’; did you mean ‘notmuch_canonicalize_file_name’? [-Wimplicit-function-declaration] | 44 | return canonicalize_file_name (path); | | ^~~~~~~~~~~~~~~~~~~~~~ | | notmuch_canonicalize_file_name | ./compat/compat.h:44:9: warning: returning ‘int’ from a function with return type ‘char *’ makes pointer from integer without a cast [-Wint-conversion] | 44 | return canonicalize_file_name (path); | | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ `---- I guess compat.h needs to define _GNU_SOURCE and include stdlib.h? ,---- | /usr/include/stdlib.h:790:14: error: conflicting types for ‘canonicalize_file_name’ | 790 | extern char *canonicalize_file_name (const char *__name) | | ^~~~~~~~~~~~~~~~~~~~~~ | In file included from notmuch-client.h:31, | from debugger.c:21: | ./compat/compat.h:44:9: note: previous implicit declaration of ‘canonicalize_file_name’ was here | 44 | return canonicalize_file_name (path); | | ^~~~~~~~~~~~~~~~~~~~~~ | make: *** [Makefile.local:204: debugger.o] Error 1 `---- I guess that's the same issue? I was thinking if we are going to have provide notmuch_canonicalize_file_name, it might make more sense to start e.g. util/path-util.{c,h}, and put the relevant inline (or not) function there. I guess either the current approach (with appropriate fixes), or putting things in util is fine. d _______________________________________________ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-leave@notmuchmail.org