Đoàn Trần Công Danh <[email protected]> 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 -- [email protected]
To unsubscribe send an email to [email protected]
