blocks|key|4397716|text|该警告是由编译器生成的，编译器能够确定您向调用传递了不正确的参数，而在第二次调用中没有。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4397717|标准定义传递不正确的参数和/或使用不正确的标志会导致未定义的行为。|4397718|这个警告不是标准所要求的，它只是对程序员的额外帮助。|4397719|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

The warning is generated by the compiler which was able to determine that you passed incorrect arguments to the call, and didn't in the second.

The standard defines that passing incorrect arguments and/or using incorrect flags results in undefined behavior.

The warning is not required by the Standard, and it is merely additional help to the programmer.

blocks|key|664752|text|我的问题是:这样的行为是否符合C99标准？|type|blockquote|depth|inlineStyleRanges|entityRanges|data|664753|这两个示例都调用未定义的行为，但不违反约束或语法规则，因此不需要诊断。|unstyled|664754|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|G|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|H|8|@]|9|@]|A|$]]|$1|E|3|-4|5|D|7|I|8|@]|9|@]|A|$]]]|F|$]]

<blockquote>
 My question is: does such a behavior comply with C99 standard?
</blockquote>

Both examples invoke undefined behavior but there is no violation of constraint or syntax rule, so no diagnostic is required.

blocks|key|4397737|text|你们有太多的争论，应该是：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4397738|#define+STRING_LITERAL++"%25u,+%25u"
snprintf(dest_buff,+sizeof(dest_buff),+STRING_LITERAL,+arg1,+arg2);|code-block|syntax|javascript|4397739|或者：|4397740|#define+STRING_LITERAL++"%25u,+%25u,+%25u"
snprintf(dest_buff,+sizeof(dest_buff),+STRING_LITERAL,+arg1,+arg2,+arg3);|4397741|缺少警告的原因是它是未定义的行为，只有当编译器聪明到认为出了问题时才会发出警告。如果字符串直接位于snprintf命令中，编译器似乎足够聪明，如果字符串间接传递，则似乎不是。|4397742|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|P|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|Q|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|R|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|S|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|N|$]]

You have too many arguments, should be either:

<pre><code>#define STRING_LITERAL "%u, %u"
snprintf(dest_buff, sizeof(dest_buff), STRING_LITERAL, arg1, arg2);
</code></pre>

or:

<pre><code>#define STRING_LITERAL "%u, %u, %u"
snprintf(dest_buff, sizeof(dest_buff), STRING_LITERAL, arg1, arg2, arg3);
</code></pre>

The reason for the lack of warning is that it is undefined behavior and the warning is only issued when the compiler is smart enough to think that something is wrong. If the string is directly in the snprintf command, the compiler is seemingly smart enough, if the string is passed indirectly it seemingly is not.

blocks|key|3905464|text|在这个例子中|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3905465|snprintf(dest_buff,+sizeof(dest_buff),+STRING_LITERAL,+arg1,+arg2,+arg3);|code-block|syntax|javascript|3905466|您正在直接传递字符串文字，而在这个字符串中|3905467|snprintf(dest_buff,+sizeof(dest_buff),+string_const,+arg1,+arg2,+arg3);|3905468|你在传递一个变量。|3905469|我假设您的编译器(不管是什么)为了警告的目的，对文本和变量的处理方式是不同的。|3905470|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|R|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|S|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|T|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|U|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|V|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|P|$]]

In this example

<pre><code>snprintf(dest_buff, sizeof(dest_buff), STRING_LITERAL, arg1, arg2, arg3);
</code></pre>

you're passing a string literal directly, while in this one

<pre><code>snprintf(dest_buff, sizeof(dest_buff), string_const, arg1, arg2, arg3);
</code></pre>

you're passing a variable.

I'm assuming your compiler (whatever one that is) treats literals differently from variables for the purposes of the warning in question.

blocks|key|664793|text|我在C99标准的附件一(公共警告)中找到了以下声明，澄清了这种情况。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|664794|1在许多情况下，一个实现可能产生警告，但没有一个被指定为本国际标准的一部分。以下是一些比较常见的情况。|blockquote|664795|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|G|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|H|8|@]|9|@]|A|$]]|$1|E|3|-4|5|6|7|I|8|@]|9|@]|A|$]]]|F|$]]

I've found the following statement in Annex I (Common warnings) of the C99 standard, that clarifies the situation.

<blockquote>
 1 An implementation may generate warnings in many situations, none of which are
 specified as part of this International Standard. The following are a few of the more common situations.
</blockquote>

Consider the following code sample:

<pre><code>#define STRING_LITERAL "%u, %u"
const char string_const[ ] = "%u, %u";

snprintf(dest_buff, sizeof(dest_buff), STRING_LITERAL, arg1, arg2, arg3);
</code></pre>

My compiler then issues a Warning: the format string ends before this argument

Now if I change the instruction to:

<pre><code>snprintf(dest_buff, sizeof(dest_buff), string_const, arg1, arg2, arg3);
</code></pre>

Then no warning is issued by the compiler.

My question is: does such a behavior comply with the C99 standard?

Format specifier without argument

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

考虑以下代码示例：#define STRING_LITERAL  "%u, %u"const char string_const[ ] = "%u, %u";snprintf(dest_buff, sizeof(dest_buff), STRING_LITERAL, arg1, arg2, arg3);然后，我的编译器发出警告:格式字符串在此参数之前结束。现在，如果我将指令更改为：snprintf

问格式说明符没有参数
EN

回答 5

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问格式说明符没有参数EN

回答 5

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问格式说明符没有参数
EN