Question

此代码：

#include <stdio.h>
#include <iostream>
using namespace std;
int main() {
  cout << fileno(stdout) << endl;
}

在此编译器中正常工作：http://sourceforge.net/projects/mingwbuilds/files/host-windows/releases/4.7.2/32-bit/threads-posix/sjlj/x32-4.7.2-release-posix-sjlj-rev6.7z

但在这个包中：http://nuwen.net/files/mingw/mingw-9.5-without-git.exe

它返回：test.cpp:5:24: error: 'fileno' was not declared in this scope

Answer 1

MinGW有fileno。从我的MinGW窗口：

$ grep -r fileno c:/mingw/include
c:/mingw/include/stdio.h:_CRTIMP int __cdecl __MINGW_NOTHROW    _fileno (FILE*);

c:/mingw/include/stdio.h:_CRTIMP int __cdecl __MINGW_NOTHROW    fileno (FILE*);
c:/mingw/include/stdio.h:#define _fileno(__F) ((__F)->_file)
c:/mingw/include/stdio.h:#define fileno(__F) ((__F)->_file)

不幸的是，哎呀，问题是MinGW做了一些非常愚蠢的事情。它使stdio.h（与GCC无关的库）的扩展的可见性成为GCC特定方言控制标志的主题。

Cygwin也有这个问题，几年前在Cygwin邮件列表的讨论中，他们强烈否认这是一个问题。

正确的方法是使用_POSIX_SOURCE，_XOPEN_SOURCE之类的功能选择宏等。（这些宏近年来已经激增，并且变得更加复杂。）

即使指定了-D_POSIX_SOURCE，MinGW也应该在命令行上服从fileno并显示--ansi。

现在的情况是，您必须妥协语言方言并接受GCC扩展和不合规，因为您希望POSIX函数声明可见。

然而，我提出了一种解决方法，它不涉及在源代码中做任何丑陋的事情。观看此内容：

gcc -Wall -ansi -pedantic -U__STRICT_ANSI__ foo.c -c

就是这样。在MinGW上，我们使用-D_POSIX_SOURCE去除GCC的宏，而不是使用像-U__STRICT_ANSI__这样的功能选择宏。

我在我的./configure脚本中添加了一项测试，以检测此情况并将-U__STRICT_ANSI__添加到CFLAGS。在我的项目中就像一个魅力。

Answer 2

您没有指定您正在使用的编译器标志，但这可能正在发生，因为您正在使用-ansi进行编译，这会强制执行严格的ANSI合规性并禁用兼容性宏。（或类似-std=c99的内容，暗示-ansi。）

尝试不使用-ansi或指定-std=gnu99之类的标准。

Answer 3

fileno不是C或C ++的一部分，而是is POSIX。因此它在Windows上没有位置。要编写可移植代码，请坚持使用C和C ++标准提供的功能。

这可能就是为什么他们不将它发送到Windows的GCC端口。相比之下，您链接到的POSIX线程实现可能依赖于它作为实现细节，以使移植代码尽可能与原始代码保持相似。

任何进一步的理由都是主观的和偏离主题的;简而言之，你必须要求他们！

nuwen.net MinGW Distro中没有`fileno（）`函数？

3 个答案: