一个ANSI C标准的实施可以在其标准库附加功能？ [英] Can an ANSI C-compliant implementation include additional functions in its standard library?

问题描述

允许包括其他类型和函数在其标准库的ANSI C标准的实施，超出该标准列举的？ （理想的答案将参照ANSI标准的相关部分。）

Is an ANSI C-compliant implementation allowed to include additional types and functions in its standard library, beyond those enumerated by the standard? (An ideal answer would reference the relevant part of the ANSI standard.)

我问，特别是因为Mac的OS 10.7声明函数getline 函数在stdio.h，即使使用 -ansi <用gcc或铿锵编译时/ code>标记。这打破了自己定​​义函数getline 函数几个旧程序。这为Mac OS 10.7的错吗？ （该手册页函数getline 在Mac OS 10.7指出，函数getline 符合POSIX.1标准，排在2008年。）

I ask particularly because Mac OS 10.7 declares the getline function in stdio.h, even when compiling with gcc or clang using the -ansi flag. This breaks several older programs that define their own getline function. Is this a fault of Mac OS 10.7? (The man page for getline on Mac OS 10.7 says that getline conforms to the POSIX.1 standard, which came in 2008.)

编辑：为了澄清，我觉得很奇怪，包括在Mac OS 10.7的ANSI C89程序stdio.h中还拉在声明中函数getline 函数，因为函数getline 不是在K＆放列举的功能之一; R（和presumably ANSI）stdio.h中的描述。尤其是，试图编译 noweb ：

To clarify, I find it odd that including stdio.h in an ANSI C89 program on Mac OS 10.7 also pulls in the declaration for the getline function, since getline is not one of the functions enumerated in the K&R (and presumably ANSI) description of stdio.h. In particular, attempting to compile noweb:

gcc -ansi -pedantic    -c -o notangle.o notangle.c
In file included from notangle.nw:28:
getline.h:4: error: conflicting types for ‘getline’
/usr/include/stdio.h:449: error: previous declaration of ‘getline’ was here

它是在Mac OS 10.7的错误包括为ANSI C89标准编译即使函数getline 在stdio.h？

推荐答案

从第7.1.3节n1570第2款（这是C1X的草稿）：

From section 7.1.3 paragraph 2 of n1570 (which is a draft of C1x):

没有其它标识符是保留。

No other identifiers are reserved.

这是指函数getline 不应该被定义的一部分＆LT; stdio.h中＆GT; ，因为它不是根据该规范保留标识符。所以，如果你的库定义函数getline 在＆LT; stdio.h中＆GT; ，它不与C标准符合技术要求..

This is the part that means getline shouldn't be defined by the <stdio.h>, since it's not a reserved identifier according to the spec. So if your library defines getline in <stdio.h>, it's not technically compliant with the C standard...

不过，你的应的能够使用的功能测试宏导致函数getline 到＆LT是不确定的; stdio.h中方式＆gt;

However, you should be able to use the feature test macros to cause getline to be undefined in <stdio.h>.

#undef _POSIX_C_SOURCE
#define _POSIX_C_SOURCE 200112L
#include <stdio.h>

这会给你只能从旧POSIX标准的定义。这会不会对一些GNU C ++实现的工作，这就是非常令人沮丧的一些人。

This will give you only the definitions from the older POSIX standards. This won't work on some GNU C++ implementations, which is ExTrEmeLY fruSTRaTiNG for some folks.

手册页的相关部分（从glibc的手册页拍摄，对不起...）

The relevant section of the manpage is (taken from a glibc manpage, sorry...)

   Feature Test Macro Requirements for glibc (see feature_test_macros(7)):

       getline(), getdelim():
           Since glibc 2.10:
               _POSIX_C_SOURCE >= 200809L || _XOPEN_SOURCE >= 700
           Before glibc 2.10:
               _GNU_SOURCE

手册页的这部分告诉你哪个宏需要它，以获得定义值定义。我敢打赌， _POSIX_C_SOURCE 已经由编译器定义的 200809L 。

功能测试宏的想法是，如果你定义的宏，如 _POSIX_C_SOURCE ， _BSD_SOURCE ， _XOPEN_SOURCE ，等你想要的值，你不需要担心新的库函数与现有的职能冲突。还有 _GNU_SOURCE ，果然的所有的上，如果您使用的glibc，但我建议给宏观敬而远之。

The idea of feature test macros is that if you define your macros, like _POSIX_C_SOURCE, _BSD_SOURCE, _XOPEN_SOURCE, etc. to the values you want, you won't need to worry about new library functions clashing with your existing functions. There is also _GNU_SOURCE, which turns everything on if you use glibc, but I suggest giving that macro a wide berth.

这篇关于一个ANSI C标准的实施可以在其标准库附加功能？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！