我的问题主要与section four, paragraph six有关。
这两种符合规范的实施方式是托管和独立的。符合要求的托管实现应接受任何严格符合的程序。
据我所知,这构成了典型的应用程序环境,包括文件系统,分配内存和线程......
符合标准的独立实施应接受任何严格符合的程序,其中使用库条款(第7条)中规定的特征仅限于标准标题
<float.h>
,<iso646.h>
的内容,<limits.h>
,<stdalign.h>
,<stdarg.h>
,<stdbool.h>
,<stddef.h>
,<stdint.h>
和<stdnoreturn.h>
。
...这构成了典型的内核和/或嵌入式的最小环境,没有具有标准文件系统,分配内存或线程(以及其他内容)。
符合要求的实现可能具有扩展(包括其他库函数),前提是它们不会改变任何严格符合程序的行为。
似乎这使得托管实现可以自由地将自己称为托管或独立实现,当涉及到文件系统,分配内存或线程(以及其他内容)时,这些可以归入扩展< / em> category,以便它只能实现一个接口,该接口每次都返回一个指示错误的值。仅举几例:
fopen
,fgets
和malloc
可以返回NULL
fprintf
,fscanf
,fputc
和fgetc
可以返回EOF
thrd_create
可以返回thrd_error
(表示“请求无法兑现”)这意味着区分第四节第六段给出的内容实际上毫无意义。是否有任何要求保证托管和独立实施中这些功能的某些实际功能级别?例如,是否要求上述函数实际上能够返回除相应故障值之外的其他函数?
答案 0 :(得分:12)
引用的段落已经说明了这一点。
托管执行环境也是独立的,但反之亦然。编译器只需要提供独立的实现。例如,gcc严格来说是独立的,因为标准库不包括在内。但是,它假定在编译托管环境时可以使用它(默认值),假设lib在系统上可用(如glibc)。见here
简而言之,独立只是语言。它不需要支持任何库和几个标题(主要用于常见类型和实现特定的东西,如数字限制等)。这意味着标准库不需要存在 - 相应的标题也不存在。原因是一个独立的环境,很可能不会有文件,显示等设施。它用于内核,裸机嵌入等。
请注意,例如gcc,如果编译托管环境(-fhosted
),则假设标准库中使用的函数具有相应的含义,并且可能应用非常积极的优化(它构建了许多这些函数)在)。对于独立式,它实际上没有,因此您可以使用函数strcmp
,例如具有完全不同的语义。但是,它假定存在mem ...-函数,因为这些函数用于普通代码,例如,结构分配。
因此,如果为裸机构建,则应始终通过-ffreestanding
。
如果托管实现调用自身独立,则它显然不再是托管实现。然而,一旦它自己调用托管,它就必须提供标准所需的所有工具,不允许只实现虚拟变量,但必须提供标准中定义的语义。
只是说清楚:引用的部分允许独立环境省略库的所有功能,除了少数列出的标题。因此,您可以自由地提供任何其他库并使用相同的名称,但您可以做任何您喜欢的事情。因为那将是不标准库,所以不需要合规。
5.1.2.1进一步指出&#34;除了第4章要求的最小集合之外,任何可用于独立程序的库设施都是实现定义的。&#34;。这确实支持了我的发言。旁注:它也不需要main()
作为程序入口点。
答案 1 :(得分:1)
有许多种C实现,针对多种不同的执行平台,其中许多可以提供各种有用的功能,并保证其他人不能。标准的作者认为,在大多数情况下,应该足够明显应该针对各种平台和应用领域提供哪些特性和保证,以及如何提供它们,不需要有标准关注这些细节。另一方面,需要诸如文件I / O之类的应用程序的数量以及可以提供它们的平台的数量足以证明识别为&#34;特殊的&#34;那些包含这些功能的实现。
通常,旨在为独立使用而设计的实现将可用于无法有效处理托管实现的平台。虽然标准规定了一些超出某些较小C平台实际要求的要求,但C的一些几乎符合要求的实现可以非常有用地用于只有足够存储空间来保存256条指令和16字节的处理器。值得变数。如果数字厨房温度计/计时器小工具没有文件系统或控制台,为什么它会浪费存储在stdout描述符之类的东西上?
此外,由于标准没有定义独立应用程序可以执行I / O的标准方法,并且由于不同平台处理I / O的方式不同,因此几乎独立的应用程序将针对特定目标平台或平台范围。托管的实现不会暴露底层平台提供的自然特征或保证,对于运行不需要这些特性或保证的程序可能是有用的。然而,如果没有使用特定于平台的功能和保证,嵌入式程序无法做很多事情,因此,一个不允许程序员访问这些东西的独立实现将无法做到许多。质量实现应该允许程序员使用任何可以帮助他们完成他们需要做的功能或保证,尽管有些人可能需要使用编译选项来确保他们不做任何古怪的事情。出于某种原因,标准委员会认为可能存在某些实施和应用领域,其中特征或保证的价值不能证明成本是合理的,这已成为时尚。表明程序员不应期望实现提供在低级编程中有用的功能或保证,并且平台将提供基本上零成本的功能。
答案 2 :(得分:0)
标准定义的分别托管的独立实现是最小定义。两种变体都是可以在各种实际系统上合理实现的最小公分母。
定义这种最小的可行集合的理由是,指定针对这两种形式之一的程序必须看起来如何才能在理想的所有实现上均以预期结果编译并运行 conforming 各自的味道。
严格符合(即符合 )标准的程序具有最大的可移植性。
毋庸置疑,独立存在和托管的实际现有实现通常都提供大量扩展,就标准而言,这是可以的-需要说明的是,扩展不得使严格符合标准的程序无效。
回到您的问题:标准所做出的区分-理论-很清楚。 实际存在的实现(实践)在标准的最低要求之间以及超出该最低要求的范围很广,但受有关严格遵循程序(针对托管或独立实现以及不依赖任何扩展名。
顺便说一句,关于标准库虚拟函数的示例是正确的:对于独立的实现,这只是允许扩展的一个有趣案例:任何针对独立环境的严格符合规范的程序都不会调用它们。作为托管环境的一部分,它们将合规但无用。 (实际上可能会遇到某些系统资源用尽的情况,或者它们可能是测试存根实现。)
答案 3 :(得分:0)
有些独立的环境无法成为托管环境。阻止独立式环境成为托管环境的两个已知条件是:
sizeof(char) == sizeof(int);
sizeof(size_t) < sizeof(int signed);
// SIZE_MAX < INT_MAX
托管环境明确要求
sizeof(char) < sizeof(int);
// (int)EOF != (char)EOF;
sizeof(int unsigned) <= sizeof(size_t);
// UINT_MAX <= SIZE_MAX
如果sizeof(char) == sizeof(int)
,EOF
未定义。
如果为argc > SIZE_MAX
,则无法呼叫main
。