# Attribute "format printf" ignored **URL:** \ **Category:** Report False-positive / False-negative...\ **Tags:** cfamily\ **Created:** [July 11, 2025, 8:02am UTC](https://community.sonarsource.com/t/attribute-format-printf-ignored/144264 "2025-07-11T08:02:42Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![lorenzo.buzzi](https://avatars.discourse-cdn.com/v4/letter/l/f14d63/32.png) [@lorenzo.buzzi](https://community.sonarsource.com/u/lorenzo.buzzi)\ **Post date:** [July 11, 2025, 8:02am UTC](https://community.sonarsource.com/t/attribute-format-printf-ignored/144264/1 "2025-07-11T08:02:42Z")
In the code base of one of our applications, written in C, we declare and define a function that uses variable arguments and ellipsis notation: > void **xxx\_message\_dom** (int dom, int user, int log, LogType type, int fatal, **char const \*format, …** ); As expected, SonarQube signals a code smell due to the **rule c:S923** , that discourages the use of ellipsis notation since it bypasses the type checking performed by the compiler. What I do not understand is why SonarQube does not recognize the ‘format’ attribute we attached to the function. > void **xxx\_message\_dom** (int dom, int user, int log, LogType type, int fatal, **char const \*format, …** ) **attribute((format (printf, 6, 7)))**; This attribute tells the compiler where to perform type checking and I can confirm that it works as expected in case of type mismatch with the format string (it prints the appropriate warnings). IMHO the analysis should take this into account. ---
**Author:** ![ganncamp](https://dub1.discourse-cdn.com/sonarsource/user_avatar/community.sonarsource.com/ganncamp/32/1261_2.png) [@ganncamp](https://community.sonarsource.com/u/ganncamp)\ **Post date:** [July 14, 2025, 11:47am UTC](https://community.sonarsource.com/t/attribute-format-printf-ignored/144264/2 "2025-07-14T11:47:24Z")
Hi, For this false-negative report we need a few more details. I’ve moved this topic to the “Report False-positive / False-negative” category, and I need you to address the questions in that category’s topic template: > [@](#): > > Make sure to read this post before raising a thread here: > [How to Report a False-positive / False-negative](https://community.sonarsource.com/t/how-to-report-a-false-positive-false-negative/37022) > > Then tell us: > > - What language is this for? > - Which rule? > - Why do you believe it’s a false-positive/false-negative? > - Are you using > - SonarQube Cloud? > - SonarQube Server / Community Build - which version? > - SonarQube for IDE - which IDE/version? > - in connected mode with SonarQube Server / Community Build or SonarQube Cloud? > > - How can we reproduce the problem? Give us a self-contained snippet of code (formatted text, no screenshots)   Thx, Ann ---
**Author:** ![lorenzo.buzzi](https://avatars.discourse-cdn.com/v4/letter/l/f14d63/32.png) [@lorenzo.buzzi](https://community.sonarsource.com/u/lorenzo.buzzi)\ **Post date:** [July 14, 2025, 12:48pm UTC](https://community.sonarsource.com/t/attribute-format-printf-ignored/144264/3 "2025-07-14T12:48:57Z")
> - What language is this for? **C** > - Which rule? **c:S923** > - Why do you believe it’s a false-positive/false-negative? Because **attribute((format (printf, 6, 7)))** ; tells the compiler to perform type checking and it has been proven to be effective. > - Are you using > - SonarQube Cloud? > - SonarQube Server / Community Build - which version? > - SonarQube for IDE - which IDE/version? > - in connected mode with SonarQube Server / Community Build or SonarQube Cloud? I am using **SonarQube for Visual Studio Code** , but **not** in connected mode (since SonarQube Server is set to operate on another branch). > - How can we reproduce the problem? Give us a self-contained snippet of code (formatted text, no screenshots) **In test.h declare:** ```auto void xxx_message_dom (int dom, int user, int log, int type, int fatal, char const *format, … ) attribute((format (printf, 6, 7))) ; ``` **In test.c define and use:** ```auto void xxx_message_dom (int dom, int user, int log, int type, int fatal, char const *format, … ) { va_list ap; // Insert something here to make use of dom, user, log, type, and fatal // so that SonarQube do not complain about unused arguments. va_start(ap, format); vprintf(format, ap); va_end(ap); } ``` ---
**Author:** ![ganncamp](https://dub1.discourse-cdn.com/sonarsource/user_avatar/community.sonarsource.com/ganncamp/32/1261_2.png) [@ganncamp](https://community.sonarsource.com/u/ganncamp)\ **Post date:** [July 14, 2025, 12:55pm UTC](https://community.sonarsource.com/t/attribute-format-printf-ignored/144264/4 "2025-07-14T12:55:47Z")
Hi, Thanks for these details! What’s your SonarQube for VSCode version? And if it’s not 4.26, can you upgrade and make sure this is still replicable?   Thx, Ann ---
**Author:** ![lorenzo.buzzi](https://avatars.discourse-cdn.com/v4/letter/l/f14d63/32.png) [@lorenzo.buzzi](https://community.sonarsource.com/u/lorenzo.buzzi)\ **Post date:** [July 14, 2025, 2:38pm UTC](https://community.sonarsource.com/t/attribute-format-printf-ignored/144264/5 "2025-07-14T14:38:37Z")
The **SonarQube for Visual Studio Code** in use is the **4.26.0**. I actually compile wrapping the `make` process with the **build wrapper v6.62**. ---
**Author:** ![ganncamp](https://dub1.discourse-cdn.com/sonarsource/user_avatar/community.sonarsource.com/ganncamp/32/1261_2.png) [@ganncamp](https://community.sonarsource.com/u/ganncamp)\ **Post date:** [July 14, 2025, 2:42pm UTC](https://community.sonarsource.com/t/attribute-format-printf-ignored/144264/7 "2025-07-14T14:42:01Z")
Hi, Thanks for the details! I’ve flagged this for the language experts.   Ann ---
**Author:** ![JolyLoic](https://dub1.discourse-cdn.com/sonarsource/user_avatar/community.sonarsource.com/jolyloic/32/199_2.png) [@JolyLoic](https://community.sonarsource.com/u/JolyLoic)\ **Post date:** [July 15, 2025, 10:02am UTC](https://community.sonarsource.com/t/attribute-format-printf-ignored/144264/9 "2025-07-15T10:02:07Z")
Hi @lorenzo.buzzi, We agree that we should exclude from the C version of the rule functions that are decorated in a way that allows compilers to detect argument mismatch. I [created a ticket](https://sonarsource.atlassian.net/browse/CPP-6680) to add this exclusion. Since such decoration is compiler-specific, and since the language provided better alternatives, we still intend to report such code for C++. Let us know what you think of that. ---
**Author:** ![lorenzo.buzzi](https://avatars.discourse-cdn.com/v4/letter/l/f14d63/32.png) [@lorenzo.buzzi](https://community.sonarsource.com/u/lorenzo.buzzi)\ **Post date:** [July 15, 2025, 11:31am UTC](https://community.sonarsource.com/t/attribute-format-printf-ignored/144264/11 "2025-07-15T11:31:00Z")
Hi @JolyLoic and thank you for your prompt answer. I agree 100%.