c - glibc 中的 fxprintf.c 中如何将多字节字符串转换为宽字符字符串？

Question

目前，glibc source of perror 中的逻辑是这样的:

如果 stderr 是定向的，按原样使用它，否则 dup() 它并在 dup( )'ed fd.

如果stderr 是面向宽的，则以下逻辑来自stdio-common/fxprintf.c使用:

size_t len = strlen (fmt) + 1;
wchar_t wfmt[len];
for (size_t i = 0; i < len; ++i)
  {
    assert (isascii (fmt[i]));
    wfmt[i] = fmt[i];
  }
res = __vfwprintf (fp, wfmt, ap);

格式化字符串转换为宽字符形式的代码如下，我看不懂:

wfmt[i] = fmt[i];

此外，它使用 isascii 断言:

assert (isascii(fmt[i]));

但是在宽字符程序中格式字符串并不总是 ascii，因为我们可能使用 UTF-8 格式字符串，它可以包含非 7 位值。为什么我们运行以下代码时没有断言警告(假设 UTF-8 语言环境和 UTF-8 编译器编码)？

#include <stdio.h>
#include <errno.h>
#include <wchar.h>
#include <locale.h>
int main(void)
{
  setlocale(LC_CTYPE, "en_US.UTF-8");
  fwide(stderr, 1);
  errno = EINVAL;
  perror("привет мир");  /* note, that the string is multibyte */
  return 0;
}

$ ./a.out 
привет мир: Invalid argument

---

我们可以在面向宽的 stderr 上使用 dup() 使其不面向宽吗？在这种情况下，可以在不使用这种神秘转换的情况下重写代码，考虑到 perror() 仅采用多字节字符串 (const char *s) 并且语言环境消息无论如何都是多字节这一事实。

事实证明我们可以。以下代码演示了这一点:

#include <stdio.h>
#include <wchar.h>
#include <unistd.h>
int main(void)
{
  fwide(stdout,1);
  FILE *fp;
  int fd = -1;
  if ((fd = fileno (stdout)) == -1) return 1;
  if ((fd = dup (fd)) == -1) return 1;
  if ((fp = fdopen (fd, "w+")) == NULL) return 1;
  wprintf(L"stdout: %d, dup: %d\n", fwide(stdout, 0), fwide(fp, 0));
  return 0;
}

$ ./a.out 
stdout: 1, dup: 0

顺便说一句，是否值得向 glibc 开发人员发布有关此改进的问题？

---

注意

使用 dup() 在缓冲方面受到限制。我想知道在glibc 中perror() 的实现中是否考虑了它。以下示例演示了此问题。输出不是按照写入流的顺序，而是按照缓冲区中数据被注销的顺序。请注意，输出中值的顺序与程序中的顺序不同，因为 fprintf 的输出首先被注销(因为“\n”)，而 fwprintf 的输出在程序退出时被注销。

#include <wchar.h>
#include <stdio.h>
#include <unistd.h>
int main(void)
{
  wint_t wc = L'b';
  fwprintf(stdout, L"%lc", wc);

  /* --- */

  FILE *fp;
  int fd = -1;
  if ((fd = fileno (stdout)) == -1) return 1;
  if ((fd = dup (fd)) == -1) return 1;
  if ((fp = fdopen (fd, "w+")) == NULL) return 1;

  char c = 'h';
  fprintf(fp, "%c\n", c);
  return 0;
}

$ ./a.out 
h
b

但是如果我们在fwprintf中使用\n，输出结果和程序中一样:

$ ./a.out 
b
h

perror() 设法摆脱了它，因为在 GNU libc 中 stderr 是无缓冲的。但是它能在 stderr 手动设置为缓冲模式的程序中安全运行吗？

---

这是我建议给 glibc 开发人员的补丁:

diff -urN glibc-2.24.orig/stdio-common/perror.c glibc-2.24/stdio-common/perror.c
--- glibc-2.24.orig/stdio-common/perror.c   2016-08-02 09:01:36.000000000 +0700
+++ glibc-2.24/stdio-common/perror.c    2016-10-10 16:46:03.814756394 +0700
@@ -36,7 +36,7 @@

   errstring = __strerror_r (errnum, buf, sizeof buf);

-  (void) __fxprintf (fp, "%s%s%s\n", s, colon, errstring);
+  (void) _IO_fprintf (fp, "%s%s%s\n", s, colon, errstring);
 }


@@ -55,7 +55,7 @@
      of the stream.  What is supposed to happen when the stream isn't
      oriented yet?  In this case we'll create a new stream which is
      using the same underlying file descriptor.  */
-  if (__builtin_expect (_IO_fwide (stderr, 0) != 0, 1)
+  if (__builtin_expect (_IO_fwide (stderr, 0) < 0, 1)
       || (fd = __fileno (stderr)) == -1
       || (fd = __dup (fd)) == -1
       || (fp = fdopen (fd, "w+")) == NULL)

Answer 1

注意:在这篇文章中找到具体问题并不容易；总的来说，该帖子似乎试图参与有关 glibc 实现细节的讨论，在我看来，最好将其定向到专门针对该库开发的论坛，例如 libc-alpha mailing list . (或查看 https://www.gnu.org/software/libc/development.html 了解其他选项。)恕我直言，这种讨论不太适合 StackOverflow。尽管如此，我还是尽力回答了我能找到的问题。

1. wfmt[i] = fmt[i];如何从多字节转换为宽字符？

   实际上，代码是:

   assert(isascii(fmt[i]));
   wfmt[i] = fmt[i];
   

   这是基于 ascii 字符的数值与 wchar_t 相同这一事实。严格来说，不必如此。 C标准规定:

   Each member of the basic character set shall have a code value equal to its value when used as the lone character in an integer character constant if an implementation does not define __STDC_MB_MIGHT_NEQ_WC__. (§7.19/2)

   (gcc 没有定义那个符号。)

   但是，这仅适用于基本集中的字符，而不适用于 isascii 识别的所有字符。基本字符集包含 91 个可打印的 ascii 字符以及空格、换行符、水平制表符、垂直制表符和换页符。因此，理论上可能无法正确转换剩余的控制字符之一。但是，调用 __fxprintf 时实际使用的格式字符串仅包含基本字符集中的字符，因此在实践中，这种迂腐的细节并不重要。

2. 为什么执行perror("привет мир");时没有assert警告？

   因为只转换格式字符串，格式字符串(即"%s%s%s\n")只包含ascii字符。由于格式字符串包含 %s(而不是 %ls)，参数应该是 char*(而不是 wchar_t *) 在窄字符和宽字符方向。

3. 我们可以在面向宽的 stderr 上使用 dup() 使其不面向宽吗？

   那可不是个好主意。首先，如果流有方向，它也可能有一个非空的内部缓冲区。由于该缓冲区是 stdio 库的一部分而不是底层 Posix fd 的一部分，因此它不会与重复的 fd 共享。因此，由 perror 打印的消息可能会插入到某些现有输出的中间。此外，多字节编码可能具有移位状态，并且输出流当前不处于初始移位状态。在这种情况下，输出 ascii 序列可能会导致输出出现乱码。

   在实际实现中，dup只对没有方向的流进行；这些流从来没有针对它们的任何输出，因此它们肯定仍处于初始移位状态且缓冲区为空(如果流被缓冲)。

4. 是否值得向 glibc 开发人员发布有关此改进的问题？

   这取决于你，但不要在这里做。这样做的正常方法是提交错误。没有理由相信 glibc 开发人员阅读了 SO 问题，即使他们阅读了，也必须有人将问题复制为错误，并复制任何建议的补丁。