=?utf-8?q?Félix?= Cloutier <fclout...@apple.com>, =?utf-8?q?Félix?= Cloutier <fclout...@apple.com>, =?utf-8?q?Félix?= Cloutier <fclout...@apple.com>, =?utf-8?q?Félix?= Cloutier <fclout...@apple.com>, =?utf-8?q?Félix?= Cloutier <fclout...@apple.com>, =?utf-8?q?Félix?= Cloutier <fclout...@apple.com>, =?utf-8?q?Félix?= Cloutier <fclout...@apple.com>, =?utf-8?q?Félix?= Cloutier <fclout...@apple.com>, =?utf-8?q?Félix?= Cloutier <fclout...@apple.com>, =?utf-8?q?Félix?= Cloutier <fclout...@apple.com>, =?utf-8?q?Félix?= Cloutier <fclout...@apple.com> Message-ID: In-Reply-To: <llvm.org/llvm/llvm-project/pull/116...@github.com>
bgra8 wrote: @apple-fcloutier it seems this patch breaks code that declares functions with multiple different `__attibute__((__format__))` specifications. One such example is the `util-linux` library (https://www.kernel.org/pub/linux/utils/util-linux/v2.41/) which has such a declaration: ``` int ul_path_scanff(struct path_cxt *pc, const char *path, va_list ap, const char *fmt, ...) __attribute__ ((__format__ (__printf__, 2, 0))) __attribute__ ((__format__ (__scanf__, 4, 5))); ``` The intention is to specify that `path` is a `printf` format and `fmt` is a `scanf` format. With the current patch, the compilers wrongfully errors when `fmt` is passed to `vfscanf` in the function implementation with the message: ``` path.c:734:18: error: passing 'printf' format string where 'scanf' format string is expected [-Werror,-Wformat] 734 | rc = vfscanf(f, fmt, fmt_ap); ``` So it looks like the compiler does not correctly identify each `format` attribute in the function declaration. Is this intended? https://github.com/llvm/llvm-project/pull/116708 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits