1

这段代码：

#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

4

3 回答 3

3

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等等。（这些宏近年来激增，变得更加复杂。）

MinGW 应该服-D_POSIX_SOURCE从命令行显示fileno，即使--ansi是指定的。

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

然而，我想出了一个解决方法，它不涉及在源代码中做任何丑陋的事情。看这个：

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

就是这样。-D_POSIX_SOURCE在 MinGW 上，我们使用-U__STRICT_ANSI__剥离 GCC 的宏，而不是使用类似的特征选择宏。

我在./configure脚本中添加了一个测试来检测这种损坏情况并添加-U__STRICT_ANSI__到CFLAGS. 在我的项目中就像一个魅力。

于 2014-01-10T03:52:38.593 回答
2

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

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

于 2013-11-05T13:19:35.437 回答
0

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

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

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

于 2013-01-05T14:52:27.727 回答