【发布时间】：2019-11-19 04:59:32
【问题描述】：
我正在编写两个函数作为打印到stderr 的便捷快捷方式：一个我调用eprintf 来打印常规字符串；和ewprintf 用于打印宽字符串。我写了eprintf如下：
int eprintf(const char* fmt, ...) {
va_list args;
va_start(args, fmt);
int written = vfprintf(stderr, fmt, args);
va_end(args);
return written;
}
ewprintf 是一样的，只是它的fmt 参数是const wchar_t* 类型，而我使用vfwprintf 来写stderr。
我在名为eprintf.h 的头文件中声明了这两个函数，然后在eprintf.c 中定义。我的主要功能只是为了测试这些：
#include <stdio.h>
#include <stdlib.h>
#include <locale.h>
#include "eprintf.h"
int main(int argc, char** argv) {
setlocale(LC_ALL, "");
ewprintf(L"This is a test.\n");
return 0;
}
我用eprintf 替换了ewprintf，然后用valgrind 测试了程序，没有任何问题——分配给释放的分配数量相同，没有标记为“仍可访问”的字节；但是，当使用ewprintf--调用vfwprintf--valgrind 时报告两个块中的5120 个字节“仍然可以访问”，有33 个分配，但只有31 个释放。运行更详细的泄漏检查以查找“仍然可访问”内存的原因，valgrind 提供了包含vfwprintf 的跟踪。
我还尝试将eprintf 和ewprintf 定义为可变参数宏，就像看到的here 一样。但是，我在将ewprintf 写成宏时遇到了同样的问题。
那么，我的第一个问题是：在这种情况下，这个“仍然可以解决”的问题实际上是否值得关注？请注意，valgrind 不会将任何字节报告为“肯定丢失”、“间接丢失”或“可能丢失”。其次，即使这实际上不是问题本身，我能做些什么来解决它吗？
更新：这是我对ewprintf 的实现，以进一步澄清：
// Notice that its parameter is a wide-character string, and it calls `vfwprintf`.
int ewprintf(const wchar_t* fmt, ...) {
va_list args;
va_start(args, fmt);
int written = vfwprintf(stderr, fmt, args);
va_end(args);
return written;
}
【问题讨论】：
-
为了消除任何误解，也许您应该向我们展示
ewprintf()功能，而不仅仅是描述与eprintf()相比的差异。 -
这是一个可以忽略的非问题。
标签： c