在C中使用sprintf的副作用与缓冲区溢出

在C中使用sprintf的副作用与缓冲区溢出,c,coding-style,C,Coding Style,以下情况会导致问题吗 my_func() { char date_field[11]; time_t current_time; time(&current_time); sprintf(date_field, "%0.3d%0.3d%.02d%0.2d\0", current_time.tm_yday, current_time.tm_year, current_time.tm_hour, current_time.tm_min); ... }

以下情况会导致问题吗

my_func()
{
  char date_field[11];
  time_t current_time;

  time(&current_time);

  sprintf(date_field, "%0.3d%0.3d%.02d%0.2d\0", current_time.tm_yday,
      current_time.tm_year, current_time.tm_hour, current_time.tm_min);

  ...
}

我意识到这可能会超出
日期\u字段
缓冲区。。。我担心的是这种情况的副作用?例如:堆芯转储?如何捕获/捕获此类问题?

按照当前编写的代码,您的代码没有编译:
current\u time
time\t
,而不是
struct tm
。如何计算
tm
结构以及如何使用它?如果此结构未正确初始化,
sprintf()
可能会调用未定义的行为,这意味着可能会发生任何情况,但这将要求某些字段超出范围

试图详细说明这样一个小而不准确的代码片段的副作用是徒劳的

通过增大缓冲区来修复代码,并使用
snprintf
而不是
sprintf
,并确保正确计算
tm
结构。无效的
date\u time
字符串,即使没有缓冲区溢出,也可能导致代码中其他地方或数据库本身出现其他问题。。。发布更多代码将有助于调查


你知道更多关于实际坠机的情况吗?您有寄存器转储吗?

为什么要对缓冲区大小感到吝啬?如果这些数字恰好违反了宽度规格,则会导致缓冲区溢出。只要多吃,你就不必担心副作用了。你真的缺少几个字节吗?顺便说一句,您不需要编写一个显式的
\0
,因为
sprintf
为您提供了这一功能。为什么不使用
snprintf
,它既能保证空值,又能保证永不溢出?您还可以通过取数据的模值来保证适合,以防止垃圾进入。如
current_time.tm_yday%1000
等。同时使用
%u
格式,您将不会得到意外的
-
符号。如果您想知道缓冲区是否溢出,请测试
sprintf
的返回值(如果尚未崩溃),该值最多必须比缓冲区大小小一个。代码不编译<代码>时间>当前时间和
当前时间。tm_yday
不是有效的C代码。我们遇到的是随机崩溃。在发生前几天,有时几个月发生。日期\时间字段用作数据写入isam文件的字段。发生这种情况时,文件将以指数级增长。我认为额外的null会破坏指针并造成严重破坏。@user3053087:你想解释什么?发布的代码中有一个bug。实际的函数可能有更多的本地数据和更多的代码围绕着有问题的代码,它也可能有更多的bug。在具有自动存储的缓冲区结尾之外写入很可能会覆盖某些其他变量或堆栈帧中更糟糕的部分。。。您所描述的是未定义行为的潜在后果。是否有任何东西阻止您修复代码?您是否正在尝试评估此错误是否解释了该行为?这是可能的,但也可能发生其他事情。是的,尝试评估此代码是否解释了我们看到的内容。明天将进行更改并进行测试。我更改了答案,代码与编写的代码不符,请发布实际代码。应用程序用户遇到的问题是,尝试将新记录插入受影响的isam文件时,行失败。它增长到一个难以想象的大文件大小(130G),然后所有试图写入该文件的进程都会得到一个c-isam错误107。奇怪的是,托管数据库文件的文件系统只有9.2G的空间。听起来像是指向太空问题的指针。