终端界面 进程 I/O 控制函数

 7.2  通用终端界面控制函数

    本条描述用于控制通用终端功能的函数。如果实现支持作业控制，那么，除非对某一命令另有说明，否则这些函数不能由后台进程使用。企图执行这些操作将导致向该进程组发送一个SIGTTOU信号。若主调进程正在屏蔽或忽略SIGTTOU信号，则允许该进程执行此操作．而不发送SIGTTOU信号。

    在所有这些函数中，fildes是打开的文卷描述字。然而，这些函数要影响的是终端文卷，而不单是影响与该文卷描述字相联系的打开的文卷说明。

7.2.1 获取和置状态

    函数：tcgetattr()、tcsetattr()

7.2.1.1 格式

    # include <termios.h> 

    int tcgetattr(int fildes,struct termios  *termios_p)；

    int tcsetattr(int fildes,int optional_actions,

                             const struct termios*termios_p)；

7.2.1.2 说明

    函数tcgetattr()应获取与由fildes涉及的对象相联系的参数，并将其存入由termios_p指向的termios结构中．允许此函数在后台执行，然而．终端属性可以被随后的前台进程改变，如果终端设备支持不同的输入和输出波特率，则由函数tcgetattr()返回的存放在termios结构中的波特率应反映实际波特率，即使它们相等．如果不支持不同的波特率，那么作为输出波特率返回的应是实际波特率，作为输入波特率返回的应是数字O或是输出波特率（作为一个符号值）。正在逐步废弃这种允许两者选一的行为，本标准的未来版本中，当不支持不同波特率时，不再允许返回0．

    函数tcsetattr()根据termios_p指向的termios结构设置与该终端（要求基础硬件支持但该硬件不可用者除外），相联系的参数如下：

    (1)若optional_actions是TCSANOW，则改变立即发生．

    (2)若optional_actions是TCSADRAIN，则参数的改变应在写到fildes的所有输出都已传输之后发生。当改变对输出有影响的参数时，应当使用本函数。

    (3)若optional_actions是TCSAFLUSH，则参数的改变在写到fildes表示的对象的所有输出都已传输之后发生，并且在对参数作出改变之前，已经接收但尚未读取的所有输入皆被丢弃，

    对于optional_actions的值的符号常量在前导文卷(termios. h)中定义。

    零波特率，BO,用于终止连结．当调用函数tcsetattr()时，若BO规定为输出速度，则modem控制线不再起作用。通常，这将断开通信线路。

    当调用函数tcsetattr()时，在termios结构中的输入波特率若等于数字零，则输入波特率将被函数tcsetattr()改为输出波特率所规定的值，就好像输入波特率已被函数cfsetispeed()置为输出波特率那样。零的这种用法正在逐步废弃．

    若函数tcsetattr()能完成某些所要求的动作，既使不是所要求的全部动作都能完成，则函数应成功返回。函数应设置所要求的且实现支持的所有属性，而所有硬件不支持的属性保持不变。如果请求的任一部分均不能被承认，则返回-1，并设置errno为EINVAL3．如果输入输出波特率不同且不支持这种

组合，那么两者均不改变，随后调用函数tcgetattr()应返回终端设备的实际状态(反映前一个函数tcse_tattr()调用已改变或未改变的状态）。函数tcsetattr()不改变termios结构中的值，不管是否实际接收了它们。

termios结构可以增加本标准未定义的附加字段。如果由termios_p指向的termios结构的值不是从对文卷描述字的函数tcgetattr()调用的结果中得到的，则函数tcsetattr()的结果是未定义的，一个严格遵循本标准的应用程序，在函数tcgetattr()和tcsetattr()调用之间，只能修改本标准定义的字段和标志，别的字段和标志保持不变。

    除了调用函数tcsetattr()或者在系统中关闭与该终端相联系的最后一个文卷描述字外，本标准的其他动作都不应使得本标准所定义的终端属性改变。

7.2.1.3 返回

成功完成时，返回0；否则，返回-1，并设置errno以指示出错。

7.2.1.4 出错

如下列任一条件发生，则函数tcgetattr（）返回-1，并把errno设置为相应的值：

    [EBADF] 实参fildes不是有效的文卷描述字。

    [ENOTTY] 与fildes相联系的文卷不是终端。

如下列任一条件发生，则函数tcgetattr（）返回-1，并把errno设置为相应的值：

    [EBADF] 实参fildes不是有效的文卷描述字。

    [EINTR] 信号中断函数tcgetattr（）。

    [EINVAL] 实参optional_actions不是合适的值，或者试图把termios结构中表示的属性改变成不支持的值。

    [ENOTTY] 与fildes相联系的文卷不是终端。

7.2.1.5 参阅

    <termios.h>，见7.1.2条。

7.2.2 通信线路控制函数

    函数：tcsendbreak()、tcdrain()、tcflush()、tcflow()

7.2.2.1 格式

    #in elude (termios. h)

    int tcsendbreak (int fildes,int duration)；

    int tcdrain (int fildes)；

    int tcflush (int 61des ,int queue_selector)；

    int tcflow (int fildes,int action)；

7.2.2.2 说明  

如果终端正在使用异步串行数据传输，那么函数tcsendbreak()在一段规定的5s内durationo值是0，则该函数使得0值位的传输时间至少持续0.25s，但不超过0.5s。若duration不是0，则输出0值位的时间由实现定义。

   如果终端不是正在使用异步串行数据传输，则是否由函数tcsendt（如实现所定义），还是不采取任何动作而返回，是实现定义的。

    函数tcdrainO等待直到所有写到由fildes涉及的对象的输出都已传输完为止。

    在成功完成时，函数tcflush()是丢弃写到由fildes涉及的对象但尚未传输的数据’或者是已接收但尚未读取的数据，由queue_selector的值来决定：

    (1)若queue_selector是TCIFLUSH，则清除已接收但尚未读取的数据。

    (2)若queue_selector是TCOFLUSH，则清除已写出但尚未传输的数据。

    (3)若queue_selector是TCIOFLUSH，则既清除已接收但尚未读取的数据，又清除已写出但尚未传输的数据。   

    函数tcflow()使fildes涉及的对象上的数据挂起传输或接收，由action的值来决定：

    (1)若action为TCOOFF，则挂起输出。

    (2)若action为TCOON，则重新启动已挂起的输出 。

    (3)若action为TCIOFF，刚系统发送一个STOP字符，用来使终端设备皙停向系统传输数据．（见7.1.2.2条输入方式中关于IXOFF的描述。）

    (4)若action为TCION，则系统发送一个START字符，用来使终端设备开始向系统传输数据（见7.1.2.2条输入方式中关于IXOFF的描述）。

    对于queue_selector和action的傅的符号常量程前导文卷(termios. h)中进行定义。

    打开终端文卷的默认动作是既不挂起它的输入也不挂起输出。

7.2.2.3 返回

    成功完成时，返回O，否则，返回-1，并设置errno以指示出错。

7.2.2.4 出错

    如下列任一条件发生，则函数tcsendbreak()返回-1，并把errno设置为相应的值：

    [EBADF]   实参fildes不是有效的文卷描述字。

    [ENOTTY]  与fildes相联系的文卷不是终端。

    如下列任一条件发生，则函数tcdrain()返回-1，并把errno设置为相应的值。

    [EBADF]    实参fildes不是有效的文卷描述字。

    [EINTR]    信号中断函数tcdrain()。

    [ENOTTY]  与fildes相联系的文卷不是终端。

    如下列任一条件发生，则函数tcflush()返回-1，并把errno设置为相应的值。

    [EBADF]    实参fildes不是有效的文卷描述字。

    [EINVAL]  实参queue selector不是合适的值。

    [ENOTTY]  与fildes相联系的文卷不是终端。

    如下列任一条件发生，则函数tcflow()返回-1，并把errno设置为相应的值：

    [EBADF]    实参fildes不是有效的文卷描述字。

    [EINVAL]  实参action不是合适的值。

    [ENOTTY]  与fildes相联系的文卷不是终端。

7.2.2.5 参阅

    <termios．h>，见7.1.2条。

7.2.3 获取前台进程组ID

    函数：tcgetpgrp()

7.2.3.1 格式

    # include (sys/types.h>

Pid_t tcgetpgrp(int fildes)；

7.2.3.2 说明

    如果{ POSIX—JOB—CONTROL}已被定义，则：

    (1)函数tcgetpgrp()返回与终端相联系的前台进程组的进程组ZD．

    (2)函数tcgetpgrp()允许由一个后台进程组的成员执行，但是信息随后可由前台进程组的成员改变。

    否则，或者实现支持如上所述的函数tcgetpgrp()，或者tcgetpgrp()调用失败。

7.2.3.3 返回

    成功完成时，函数tcgetpgrp()返回与终端相联系的前台进程组的进程组ID．如果没有前台进程组，函数tcgetpgrp()应返回一个与任何现有进程组的进程组ID都不匹配的大于1的值。否则，返回-1，并设置errno以指示出错。

7.2.3.4 出错

    如下列任一条件发生，则函数tcgetpgrp()返回-1．并把errno设置为相应的值。

    [EBADF]    实参fildes不是有效的文卷描述字。

    [ENOSYS]  实现不支持函数tcgetpgrp()。

    [ENOTTY]  主调进程没有控制终端，或者该文卷不是控制终端。

7.2.3.5 参阅

    setsid()，见4.3.2条；setpgid()，见4.3.3条ftcsetpgrp()，见7.2.4条。

7.2.4 置前台进程组ID

         函数：tcsetpgrp()

7.2.4.1 格式

    # include <sys/types.h>

    int tcsetpgrp<int fildes,pid_t pgrp_ id>；

7.2.4.2 说明

    如果{_POSIX_JOB_CONTROL}已被定义，那么：

    若主调进程有控制终端，则函数tcsetpgrp()把与该终端相联系的前台进程组ID置为pgrp_id与fildes相联系的文卷必须是主调进程的控制终端，并且该控制终端当前必须与主调进程的会晤期相联系。Pgrp_id的值必须与主调进程同一会晤期中的某个进程的进程组ID相匹配。

    否则，或者实现支持如上所述的函数tcsetpgrp()，或者函数tcsetpgrp()调用失败。

7.2.4.3 返回

    成功完成时，函数tcsetpgrp()返回oI否则，返回-1，并设置errno以指示出错。

7.2.4.4 出错

    如下列任一条件发生，则函数tcsetpgrp()返回--1，并把errno设置为相应的值：

    [EBADF]    实参fildes不是有效的文卷描述字。

    [EINVAL]  实参pgrp—id的值不是实现支持的值。

    [ENOSYS]  实现不支持函数tcsetpgrp()。

    [ENOTTY]  主调进程没有控制终端，或者文卷不是控制终端，或者控制终端不再与主调进程的会晤期相联系。

[EPERM]    pgrp_id的值是实现支持的值，但与主调进程同一会晤期中的进程的进程组ID不匹配。

 

8  针对C编程语言的语言专用服务

 

8.1  引用的C语言例程

    下面所列的函数在所标明的c语言标准的标明的章条中进行了描述．具有c语言协约的本标准包括这些函数，在本章中描述对这些函数的扩充以及在本标准中规定的其余要求。后面附有加号(+)的函数具有超出在d语言标准中规定的要求。任何宣称遵循具有c语言协约的本标准的实现都应遵循在本章中提出的要求、在本标准中其他章规定的要求以及所标明的c语言标准各章中的要求。

    有关本章的遵从性的要求，见1.3.3条及其所属各条。

    7.2  诊断

         函数：assert

    7.3  字符处理

         函数l isa[num、isalpha、iscntrl、isdigit、isgraph、islower、

         isprint、ispunct、isspace、isupper、isxdigit, tolower、

         toupper.

    7.4  本地化

         函数sset locale+

7.5 数学

         函数：acos, asin, atan, atan2, cos. sin, tan, cosh, sinh,

         tanh, exp, frexp, ldexp, log, loglO, roodf, pow, sqrt.

         ceil, labs, floor, fmod.

7.6 非局部跳转

         函数：setjmp, longjmp。

    7.9  输入／输出

         函数：c|earerr、fclose、feof、ferror、fflush、fgetc、fgets、

         fopen、fputc、fputs、fread、freopen、fseek、ftell、

         fwrite、getc、getchar、gets、perror、printf、fprintf、

         sprintf、putc、putchar、puts、remove、rename+、rewind、

         scanf、fscanf、sscanf、setbuf、tmpfile、tmpnam、ungetc.

7.10通用实用程序

         函数：abs、atof、atoi、atol、rand、srand、calloc、free、malloe、

         realloc、abort+、exit、getenv+、bsearch、qsort.

    7.11 字符串处理

         函数：strcpy、strncpy、strcat、strncat、strcmp、strncmp、strchr、

         strcspn、strpbrk、strrchr、strspn、strstr、strtok、str|en。

    7.12  日期和时间

          函数：time、asctime、ctime+、gmtime+、localtime+、mktime’‘

          strftime+

    遵循本标准的系统应使C语言标准中描述的“文本流”和“二进制流”之间没有差别。

    对于函数fseek()。若指定的位置超出了文卷尾，则发生如函数Iseek()中所描述的后果（见6.5.3条）。

    如果宏EXIT—SUCCESS由函数exit()使用，应计算得到零值。类似地-宏EXIT _FAILURE应计算得到非零值。

    用作函数gmtime()的实参的时间（从UNIX纪元算起的秒数）与tm结构(在前导文卷(time. h)中定义）之间的关系是：其结果应如2.2.2.77条中定义的从UNIX纪元算起的秒数的表达式所规定。其中，在结构中和在表达式中的名字对应。如果时区UCTO有效，那么对于函数locahime()和mktime()函数的实参与tm的结构的关系也一样。

8.1.1 对时间函数的扩展

称为TZ的环境变量的内容（2.6条）将由函数crime()、locahime()、st rftime()和mktime()用于超越默认的时区．TZ的值可具有下列两种形式（为清楚起见插入了空格）：

：characters

或

    std offset dst offset, rule

    如果TZ具有第一种形式（即如果第一个字符是冒号），那么冒号后面的字符将按实现定义的方式进行处理。

    扩展形式(对所有不以冒号为首字符的TZ)如下：

    stdoffset [dst Eoffset-I[,start[/time], end [/timel]]

其中：

    std和dst:三个字符以上但不多于{TZNAME MAX}个字节。用于规定标准时区或夏令时．只有std是必需的，若省略dst，则表明这个地点不使用夏令时。允许使用大写及小写字母，除了打头的冒号(：)或数字、逗号(，)、减号（-）、加号(+)和空字符NULL以外，允许使用任何字符，但它们的含义是未规定的。

Offset:指示一个必须加到当地时间上以使其达到世界协调时的值。of Sset的形式为；

           hh[：mm[：ss]]

其中分(mm)和秒(ss)是可选项，时(hh)是必须具有的项且可以是一位数字。要求在dst后跟有offset。如果没有跟随dst的offset，则夏令时被假定为标准时间的前一个小时。可以使用一位或多位数字，其值总是作为十进制效来解释。小时是0～24．的值，分和秒是O～59的值．超出范围的值可能导致未定义的行为．如果有一个先导符“-”，则这个时区在本初子午线的东部，否则就在西部（可使用可选的先导符“+”指示）。

rule： 指定何时改变到夏令时，何时从夏令时改回到标准时．rule的形式如下：

    date/time ,date/time。

    其中，第一个date描述何时从标准时改变为夏令时。第二个date指明何时调回。每个time字段描述何时以当前本地时间开始调整到另一种时间。date的格式应为下列格式之一；

    jn：  儒略历的天数n(l≤n≤365)。闰日不被计算在内。即，在所有的年历中（包括闰年）。2月28日是第59天，3月1日是第60天．要显式地指出偶然的2月29日是不可能的．

    n：   基于零的儒略历天数(O≤n≤3651，闰日将被计算在内，并且要指出2月29日是可能的。

    Mm.n.d一年中的m月，一月中的n周，一周中的第d日(O≤d≤6，1≤n≤5,1≤m≤12，这里的周5表示“在m月中最后一个d日”可以出现在第4周或第5周）。周1是第d日在月中出现的第一周。0日是星期日。

    除了不允许有先导符号（一或+）外，time的格式与offset的相同。若time未给定，则默认值是02 1 00 1 00．

    每当调用函数ctime()、strftime()、mktime()或locahime()时，应设置在外部变量tzname中所包含的时区名，犹如函数tzset()已被调用一样。

    允许应用程序改变TZ，并使已改变的TZ应用于应用程序本身。

8.1.2 对函数setlocale()的扩展

    函数: setlocale()

8.1.2.1 格式

    # include <locale．h>

    char *setlocale(int category,const char  *locale)；

8.1.2.2 说明

    函数setlocale()按照实参category（类别）和locale（地点）的值，设置、改变或查询进程的地点。对于category的可能值包括：

    LC_CTYPE

    LC_COLLATE

    LC_TIME

    LC_NUMERIC

    LC_MONETARY

    实现定义的附加类别

    对于本标准系统，环境变量的定义与上面命名的类别相一致，并且具有相同的拼法。

    category的值LC_ALL命名进程地点的所有的类ILC_ALL是一个特殊的常量，而不是一个类。环境变量LC—ALL具有如下注释的语义。

    实参locale是指向一个字符串的指针，这个字符串可能是一个显式的串、一个NULL指针或一个空串。

    若locale是一个显式的串，则除了值“C”以外，这个串的内容是实现定义的．locale的值“C”为C语言翻译规定了的最小环境。如果没有引用函数setlocale()，那么“C”地点应是进程的地点。地点名。POSIX一应被识别。对于在本标准中定义的或由C语言标准定义的那些函数来说，这个地点拥有与C 地点相同的语义。对于POSIX地点所作的超出c地点的扩展或改进可以包括在未来的修订版中，并且

    在ISO/IEC 9945的其他部分加上对POSIX地点的需求．

    若locate是一个NULL指针，则按照category的值查询进程的地点。对返回的串的内容未作规定。

    若locate是一个空申，则函数setlocale()就从由下列条件中首先得到满足的条件所确定。的环境中已指定的类取得一个新地点的名字。

    (1)如果LC_ALL在此环境中定义并且非空，那么就使用LC_ALL的值。

    (2)如果有一个在此环境中定义的非空变量具有和该类相同的名字，那就使用那个环境变量规定的值。

    (3)如果LANG在此环境中定义并且非空，那么就使用LANG的值。

    如果结果的值是一个被支持的地点，则函数setloeale()把进程地点的规定类别设置为该值且返回下面规定的值．如果结果的值没有命名一个得到支持的地点（并且非空），那么函数setlocale()就返回一个NULL指针，并且这次函数调用不改变进程的地点。如果没有非空的环境变量用来提供一个值，那么函数setlocale()把进程地点的指定类别设置成全系统的默认值、还是“c”或者“POSIX”是由实现定义的。环境变量可能的实际值是实现定义的，并且应该记入系统文档。

    除了在执行任何动作之前要做所有的出错检查外，对进程地点的所有类别的统一设置类似于逐个设置进程地点的每一个类别。为了设置进程地点的所有的类别，对函数setlocale()做如下引用：

    setlocale (LC_ALL,“  ”)；

    在这种情况下，函数。etlocale()首先核实：它们需要的全部环境变量的值（根据前述的优先-次序）都指示着得到支持的地点．如果对这些环境变量的值的搜索得出一个没得到支持的地点（并且非空）．那么函数setlocale()返回一个NULL指针，并且不改变进程的地点。如果所有环境变量都命名了得到支持的地点，那么函数。etlo。ale()继续执行，就象使用与环境变量相联系的适当的值或没有这样的值时，使用实现定义的默认值调用它来处理每一个类别时一样。

8.1.2.3 返回

    对函数setlocale()的成功调用返回相应于地点设置的一个字符串。返回的串是这样的：“使用该串和相联系的类别的下一次调用，应恢复那一部分进程地点”（c语言标准）。返回的串不应由进程修改，但可以由对函数。etlo。ale()的下一次调用所盖写。如果环境变量的值被使用过，则不要求此串是所用的环境变量的值。

8.2   C语言的输入／输出函数

    本条描述c语言标准的输入／输出函数和本标准定义的其他函数之间的相互作用。

    c语言标准中规定的对文卷名操作的所有函数应改为对路径名操作￡e语言标准中规定的所有函数在创建一个文卷时，尤如它们调用了函数creat()而创建，这个函数creat()带有适合c语言函数的值作为实参path，和下列值中的一个：

    s_IRUSRls_IWUSRls_IRGRPls_IWGRPls_IROTHls_IWOTH

作为实参mode。

    类型FILE以及术语。文卷位置指示符”和“流”是由c语言标准定义的，

    一个流认为是局限于单个进程的。在函数fork()调用之后，父进程和子进程各有不同的流．这些流共享一个打开的文卷说明。

8.2.1 流指针到文卷描述字的映射

    函数：fileno()

8.2.1.1 格式

    # include <stdio．h>

    int fileno(FILE*stream)；

8.2.1.2 说明

    函数fileno()返回一个与stream相联系的整型文卷描述字（见5.3.1条）。

在前导文卷< unistd, h)（见2.9条）中的下列符号值定义当应用程序启动时与c语言的标准输入(stdin)、标准输出(stdout)和标准出错(stderr)相联系的文卷描述字。

名称

说明

值

STDIN _ FILENO

STDOUT _ FILENO

STDERR _ FILENO

标准输入值stdin

标准输出值stdout

标准出错值stderr

O

1

2

    在函数mainfd()的入口处，这些流所处的状态与用遵循c语言标准要求的方式和如上所描述的文卷描述字由函数fdopen()打开所处的状态相同．

8.2.1.3 返回

    见8.2.1.2条。若发生错误，则返回-1，并设置errno以指示出错。

8.2.1.4 出错

    本标准没有规定为检测函数fileno()所要求的任何出错条件。某些错误可以在本标准未规定的条件下进行检测。

8.2.1.5 参阅

    open(),见5.3.1条．

8.2.2 按文卷描述字打开一个流

函数：fdopen()

8.2.2.1 格式

    # include (stdio．h)

    FILE*fdopen (int fildes, const char*type);

8.2.2.2 说明

    例程fdopen()使流与文卷描述字相联系．

    实参type是具有下列值之一的字符串；

    “r”为读打开；

    “W”为写打开；

    “a”为在文卷尾写打开；

    “r”为更新（读和写）打开；

    “W+”为更新（读和写）打开；

    “a4n为在文卷尾更新（读和写）打开。

    除了“w”和“w+”不导致文卷的截断以外，这些标志的含义恰如c语言标准为函数fopen()定义的一样。实参type的其他的值可以由实现定义．

    应用程序应保证流的方式为该打开的文卷的方式所允许。

    与新的流相联系的文卷位置指示符被设置为与文卷描述字相联系的文卷偏移指定的位鼢。流的出错指示符和文卷尾指示符应被清除．

8.2.2.3 返回

    成功完成时，函数fdopen()返回一个指向流的指针，否则返回NULL指针并设置errno以指示出错。

8.2.2.4 出错

    本标准没有规定为检测函数fdopen()所要求的任何出错条件。某些错误可以在本标准未规定的条件下进行检测。

8.2.2.5 参阅

    open(),见5.3.1条；    fopen()，见C语言标准。

8.2.3 其他FILE类型C语言函数的相互作用

    单个打开的文卷说明可以通过流和文卷描述字两者来访问。文卷描述字或流称为所引用的打开的文卷说明的柄(handle)，一个打开的文卷说明可以有若干个柄。

    柄可以由用户的动作来创建或取消而不影响相关的打开文卷说明。创建它们的途径包括函数fcntl()、dup()、fdopen()、fileno()和fork()（把现有的柄复制到新的进程）。至少函数fclose()、close()和ex-ec()可以取消柄（关闭某些文卷描述字，并取消流）。

    在可以影响文卷偏移量的操作[例如：函数read()、write()或lseek()]中从未使用的文卷描述字，在本讨论中不被认为是一个柄，但可导致成为柄(例如，作为函数fdopen()、dup()或fork()的结果）。这种例外包括基于流的文卷描述字，不管是用函数fopen()还是fdopen()创建的，只要它不被影响文卷偏移量的应用程序直接使用。[函数read()和write()隐含地影响文卷偏移量，函数leek()显式地影响文卷偏移量]。

    牵涉到任何一个柄（活动柄）的函数调用的结果在本标准其他地方定义，但是如果两个或多个柄被使用。并且其中之一是流，那么它们的动作应被调整为象下面描述的那样。如果不这样做，结果是未定义的。

    当对流执行函数fclose()或freopen()时[-freopen()的结果是这里所讨论的新流，它不可能是如其先前值的相同的打开文卷说明的柄]．或当拥有那个流的进程用函数exit()或abort()终止的时候，则认为流的柄被关闭。当对该文卷描述字设置FD_CLOEXEC时，该文卷描述字被函数close()、一exit()所关闭，或被exec函数之一所关闭。

    一个柄要成为活动柄．在最后一次使用第一个柄（当前活动柄）至第一次使用第二个柄（将来的活动柄）之间，必须先完成下面的动作，然后，第二个柄才成为活动柄。影响第一个柄文卷偏移量的应用程序的全部活动都将被挂起，直到它再次成为活动柄为止。（如果一个流函数具有影响文卷偏移缝的基础函数，这个流函数将被认为影响文卷偏移量，这些基础函数在下面描述。）

    对于应用这些规则，柄不必在相同的进程中。注意，在函数fork()之后，原来存在一个柄的地方有两个柄存在。如果这两个柄肯定要被访问，那么应用程序应确保两者都处在另一个可以先变成活动柄的状态。应用程序应为函数fork()作准备，就好像它是活动柄的一个变换。[如果这些进程之一执行的唯一动作是exec函数之一或函数exit(){不是exit}，则在那个进程中决不访问柄。]

    (1)对于第一个柄。应提供下面第一个适用的条件。在采取下面所要求的动作之后，如果柄还是打开的，则它可以被关闭。

       a)如果它是文卷描述字，则不需要任何动作。

       b)如果对于这个打开的文卷说明的任一个柄要完成的未来的动作仅仅是要关闭它，则不需要采取任何动作。

       c)如果它是非缓冲的流，则没有必要采取动作。

       d)若是行缓冲的流，并且写入流的最后一个字符是一个新行符[即，尤如putc(‘＼n’)是对此流的最近的操作]，则不需要采取任何动作。

       e)如果它是为写或附加而打开的流（但不是也为读打开），则，或者函数fflush()将发生或这个流将被关闭。

       f)如果它是为读打开的流，并且它是处在文卷尾[feof()为真]。则不需要采取任何动作。

       g)如果流用允许读的方式打开，并且基础打开文卷说明涉及一个能寻址的设备，则，或者函数fflush()将发生，或者这个流将被关闭。

       h)否则，其结果是未定义的。

    (2)对于第二个柄：如果以前的活动柄已经调用了一个函数，该函数显式地改变了文卷偏移擞，则除了如上对于第一个柄所要求的以外，应用程序还应执行函数lseek()或fseek()，（与柄类型相适应）使文卷偏移到一个适当的位置。

    (3)如上述对于第一个柄的要求被满足之前，活动柄不再是可访问的，则这个打开的文卷说明的状态变为未定义的．例如，这可能在函数fork()或-exit()期间发生。

    (4) exec函数需被认为使所有在这些函数被调用时是打开的流都变成不可访问的，而与什么样的流或文卷描述字对于新的进程映象可能是可用的无关．

    (5)当遵循上述规则时，不管所用柄的顺序，实现应保证一个应用程序得到正确的结果（在写操作时，没有数据被丢失或重复，除由seeks要求外，所有数据都按次序写）．即使该应用程序由多个进程组成也是如此．如果不遵循上述规则，其结果是未规定的．在遵循这些规则时，所有输入是否或在什么条件下只被看到一次是由实现定义的。

    (6)每一个对流进行操作的函数被认为有0个或多个基础函数，这意味着流函数与基础函数共享一定的特征，然而在流函数的实现和它的基础函数之间并不需要有任何关系。

    (7)在以下条中，还给出了对于超出了C语言标准的标准1/0例程的附加要求。

8.2.3.1 函数fopen()

    函数fopen()将象函数open()那样分配一个文卷描述字。

    基础函数是函数open()。

8.2.3.2 函数fclose()

    函数fclose()对与FILE流相联系的文卷描述字执行一个close()函数，如果这个流是可写的-并且如果已缓冲的数据还没有被写到文卷中去，则它还为基础文卷的st_time字段和st_mtime字段打上更新标记。

    基础函数是函数write()和close()。

8.2.3.3 函数freopen()

    函数freopen()有函数fclose()和fopen()=者的性能。

8.2.3.4 函数fflush()

    如果流是可写的并且如果已缓冲的数据还没有被写到文卷中去，则函数fflush()为基础文卷的st_crime字段和st_mtime字段做更新标记。

    基础函数是函数read()、write()和Iseek()。

8.2.3.5 函数fgetc()、fgets()、fread()、getc()、getchar()、gets()、scanf()、fscanf()

这些函数可以对st_atime字段做更新标记。这些函数之一在第一次成功运行时(返回不是由前次函数ungetc()调用提供的数据）应为st_atime字段做更新标记。

    基础函数是函数read()和Iseek()。

8.2.3.6 函数fputc()、fputs()、Iwrite()、putc()、putchar()、puts()、printf()、fprintf()

    在这些函数之一的成功执行与对同一个流的下一次函数fclose()或fflush()调用的成功完成，或者是函数exit()或abort()调用的成功完成之间，应对文卷的st_ctime字段和st_mtime字段做更新标记。

    基础函数是函数Write()和lseek()。

    如果函数fwrite()写入的字节数大于零但小于所请求的数目，则应设置流的出错指示符。如果基础函数write()报告出错，那么函数fwrite()不应修改errno。并且应设置流的出错指示符。

    如果实现提供了c语言标准中的函数vprintf()和vfprintf()，则这些函数也应遵循本标准为函数print()和fprintf()（分别）规定的限制。

8.2.3.7 函数fseek()、rewind()

如果流是可写的，并且已缓冲的数据还没有被写到文卷中去，则这些函数为这个文卷的st_ctime字段和st_mtime字段做更新标记。

函数tzset()使用环境变量TZ的值来设置由函数localtime()、ctime()、strftime()和mktime()使用的时间转换信息。如果环境中无TZ，则使用实现定义的默认时区信息a

    函数tzset()应设置外部变量tzname；

        extern char*tzname[2]={“std”,“dst”)；

    其中std和dst如8.1.1条中所述。

 

9  系统数据基

9.1  系统数据基

    本章描述的几个函数允许应用程序访问下述两个系统数据基。

    group（组）数据基包含下列每个分组的信息；

        (1)组名；

        (2)组ID号；

        (3)该组中允许的所有用户清单。

    user（用户）数据基对每一个用户包含下列信息：

(1)用户名；

        (2)用户ID号；

        (3)组ID号；

        (4)初始工作目录；

        (5)初始用户程序。

    若初始用户程序字段为空，则使用系统默认值。

    若初始工作目录字段为空，则对该字段的解释由实现定义。

    这两个数据基可以包含由本标准未规定的其他字段。

9.2  对数据基的访问

9.2.1 对组数据基的访问

    函数；getgrgid()、getgrnam()

9.2.1.1 格式

    # include (sys/types. h)

    #include <grp．h>

    struct group  *getgrgid (gid_t gid)；

    struct group  *getgrnam(eonst char *name),

9.2.1.2 说明

    函数getgrgid()和getgrnam()-者都返回一个指向类型为struct group的对象的指针，此对象中包含有组数据基中与gid或name相匹配的项。结构group在前导文卷(grp. h)中定义，它包含有表33所示的成员：

表33  group结构

    成员类型

    成员名

    说    明

char  *

gid _ t

char  *  *

 

gr _ name

gr _ gld

gr _ mere

 

    组名

    组ID号

    以空终结的指针向

    量，指向各个成员名。

 

9.2.1.3 返回

    出错时或请求的项未找到时，返回NULL指针。

    返回值可以指向静态数据，该静态数据由每次调用所盖写。

9.2.1.4 出错

    本标准没有规定为检测函数getgrgid()或getgrnam()所要求的任何出错条件。某些错误可以在本标准未规定的条件下进行检测。

9.2.1.5 参阅

    getlogin()，见4.2.4条。

9.2.2 对用户数据基的访问

    函数：getpwuid()、getpwnam()

9.2.2.1 格式

    # include (sys/type．h>

    # include (pwd．h)

    struct passwd*getpwuid(uid—t uid)l

    struct passwd  *getpwnam(const char  *name);

9.2.2.2 说明

    函数get pwuid()和getpwnam()二者都返回一个指向类型为struct passwd的对象的指针，此对象中包含有组数据基中与uid或name相匹配的表项。结构passwd在前导文卷(pwd.h>中定义．它包含有表34所示的成员：

表34  passwd结构

    成员类型 

    成员名

    说    明

char

uid_t

gid_t

char

char

pw_name

pw_uid

pw_gid

pw_dir

pw_shell

    用户名

    用户1D号

    组ID号

    初始工作目录

    初始用户程序

 

9.2.2.3 返回

    出错时或请求的项未找到时，返回NULL指针。

    返回值可以指向静态数据，该静态数据由每次调用所盖写。

9.2.2.4 出错

    本标准没有规定为检测函数getpwuid()或getpwnam()所要求的任何出错条件。某些错误可以在本标准未规定的条件下进行检测：

9.2.2.5 参阅

  getlogin()，见4.2.4条。

 

10  数据交换格式

 

10.1  档案文卷格式及交换文卷格式

    一个遵循标准的系统应提供一种机制，它能够利用此处描述的交换格式把文卷从存储媒体拷贝到文卷层次中，或从文卷层次中拷贝到存储媒体中。本标准不定义这种机制。

    当不具有适当特权的进程用上述机制从媒体中拷贝文卷时，如果已知实参mode与由扩展的tar格式的mode字段或扩展的cpio格式的c_mode字段提供的权限相符，则应把保护信息（属主及访问权限）设置成与函数crest()所设置的相同的方式。当具有适当特权的进程拷贝文卷时，除了10.1.1条中所描述的对于tar使用符号的用户和组ID之外，应准确地恢复记录在媒体上的文卷属主及权限。

    格式创建实用程序用于把文卷系统转换到本条所定义的格式。而格式读实用程序则用于由本条所定义的格式向文卷系统转换。这些实用程序的界面，包括它们的名字，由实现定义。

    这些格式的首部(header)规定使用GB 1988字符。但对文卷本身的内容并没有限制．文卷中的数据可以是二进制数据，也可以是用户可用的任何形式的文本。当这些格式用于在源级上传送文本时，所有的字符都应是GB 1988基准版本(IRV)中的字符。

    本标准未规定媒体的格式和数据在媒体上的组织形式。

    注：一些准则和建议请见附录B（参考件）。

10.1.1 扩展的tar格式

    扩展的tar档案磁带或文卷包含一系列的块。每个块固定为512字节（见下面）。虽然这种格式可以被认为存储在9道的标准12.7mm(O.5in)磁带上，但也不排除其他类型的可移动的媒体。每一个档案文卷由描述文卷的首都块表示，接着是零个或多个有该文卷内容的块。档案文卷的末尾有两个写满二进制0的块，作为档案文卷结束指示器。

上面所提的若干个块可按物理I/O操作分成组。每n个块（n由生成档案文卷的应用实用程序设置）组成一组，可由单个write()操作完成写入．在磁带上这种写入的结果是单个的磁带记录。最后一个块组总是满长度的，所以两个0块之后的块含有未定义的数据。

首部块的结构见表35．所有的长度值、偏移量都是十进制的．

表35  tar首部块

    字段名

字节偏移量

长度（字节）

    文卷名( rta me)

    方式(mode)

    用户标识(uid)

    组标识(gid)

    长度(size)

    修改时间(mtime)

    校验和(chksum)

    类型标志(typeflag)

    链接名(linkname)

    幻数( magic)

    版本(version)

    用户名(uname)

    组名(gname)

    主设备号(devmajor)

    次设备号(devminor)

    前缀(prefix)

0

100

108

116

124

136

148

156

157

257

263

265

297

329

337

345

l00

8

8

8

12

12

8

l

100

6

2

32

32

8

8

155

 

首都块用到的符号常量在前导文卷<tar.h>中定义如下：

    # define TMAGIC  “ustar”／*ustar及空*／

    # define TMAGLEN  6

#defineTVERSION "00" I* 00及非空*/

# define TVERSLEN  2

／*用于类型标志(typeflag)字段的值*／

#define REGTYPE  'o’／*普通文卷*／

# define AREGTYPE' \0'/*普通文卷*／

# define LNKTYPE  '1’／*链接*／

#define SYMTYPE  '2’／*保留*／

#define CHRTYPE  '3’／*字符特别文卷*／

#define BLKTYPE  '4’／*块特别文卷*／

#define DIRTYPE  '5’／*目录文卷*／

#define FIFOTYPE  '6’／*FIFO特别文卷*／

#define CONTTYPE  '7’／*保留*／

／*在方式字段使用的位，值用八进制表示*／

#define TSUID 0 4000／*执行时调整用户ID*／

#define TSGID 0 2000／*执行时调整组ID*／

#define TSVTX 0 1000 ／*保留*／

                          ／*文卷权限*／

    #define TUREAD 00400／*文卷主可读*／

    #define TUWRITE 00200 ／*文卷主可写*／

    #define TUEXEC 00100 ／*文卷主可执行／可搜索*／

    #define TGREAD 00040／*组可读*／

    #define TGWRITE 00020 ／*组可写*／

    #define TGEXEC 00010 ／*组可执行／可搜索*／

    #define TOREAD 00004 ／-其他用户可读*／

    #define TOWRITE 00002 ／*其他用户可写*／

    #define TOEXEC 00001 ／*其他用户可执行／可搜索*／

    所有字符都用GB 1988编码字符集中的字符表示．为了在不同实现之间获得最大的可移植性，文卷名应从可移植文卷名字符集中奇偶位为O的、用8位表示的字符中选择。如果一个实现支持在文卷名、用户名、组名中使用可移植文卷名字符集以外的字符集，那么，一个或多个实现所定义的这些字符集的编码应被提供用于交换的目的。然而格式读实用程序绝不应在本地系统创建一个不能通过本标准前面所描述的函数来访问的文卷名l见5.3.1、5.6.2、5.2.1、6.5.2及5.1.2条。如果在可以创建无效文卷名的媒体上找到一个文卷名，实现应定义文卷中的数据是否存储在文卷层次中，并以什么名字存储。格式读实用程序可以抉择以忽略这些文卷，只要它产生指示文卷被忽略的错误。

    在首都块内的每个字段都是连续的，即不填加其他内容，在档案媒体上，字符也是被连续存放的。

    字段magic、uname和gname都是以空终结的字符串。字段name、linkname和prefix也都是以空终结的字符串，除非数组中所有字符（包括最后一个字符）都是非空字符．字段version具有两个字节，含字符“00”，字段typeflag包含单个的字符，所有其他字段都是以O打头的八进制数，使用GB 1988 IRV中的数字，每个数值字段以一个或多个空格或空字符来终结。

  字段name和prefix构成文卷的路径名。文卷的层次关系通过指定路径名作为路径前缀、斜线字符和文卷名作为后缀来保持．如果prefix不是一个空串（它的第一个字符不是空字符），则通过串接prefix（直到第一个空字符为止）、斜线和字符name就构成了一个新的路径名；否则，就单独使用name。

    这种文卷视为普通文卷（类型’O’）．

    ’A’～ Z’：留给客户实现使用，所有其他的值都留给本标准在今后的版本中的规格说明。

    字段magic说明档案以文卷档案格式输出。如果该字段包含TMAGIC，则字段uname和gname应分别包含文卷主和组的GB 1988 IRV表示（如果有必要，可进行适当的截取）．当文卷由具有特权的用户进行恢复时，为了查找到这些文卷名应扫描实用程序的保存的保留版本、口令及组文卷。如果找到。那么使用在这些文卷内的用户ID和组ID，而不使用在uid和gid字段中的值。

    首部的编码被设计成在机器之间是可移棒的．

10.1.1.1 参阅

    <grp.h>，见9.2.1条；<pwd．h>，见9.2.2条；<sys/stat.h>,见5.6.1条；

    star()，见5.6.2条；(unistd．h>，见2.9条。

10.1.2 扩展的cpio格式

    面向字节的cpio档案格式是一系列的项，每项由描述文卷的首部、文卷名及文卷内容所组成。一个档案可以被记录为一系列固定长度的字节块．使用这种分块只是使物理I/O更有效。块的最后一组总是金长度的。

对于面向字节的cpio档案格式，每个项的信息必须按表36描写的顺序排列。

表36面向字节的cpio档案表项

首部

字段名

长度（字节）

解释为

    C_幻数（c_maglc)

    c_设备号(c_dev)

c_索引节点号(c_ino)

    c_方式(c_mode)

    c_用户标识(c_uid)

    c_组标识(c_gid)

    c_链接计数(c_nlink)

    c_特别文卷设备号(c_rdev)

    c_最后修改时间(c_retiree）

    c_文卷名长度(c_rmmesize)

    c_文卷长度(c_filesize)

6

6

6

6

6

6

6

6

11

6

11

八进制数

八进制数

八进制数

八进制数

八进制数

八进制数

八进制数

八进制数

八进制数

八进制数

八进制数

 

文卷名字

    字段名

    长度

    解释为

    c_name

    c_namesize

    路径名称字符串

 

文卷数据

    字段名

    长度

    解释为

    c_filedata

    c_fUesize

    数据

 

10.1.2.1  cpio首部

    对于档案中的每个文卷，应写有如前面所定义的首都。首部各字段中的信息应写成八进制数字表示的GB 1988字符流．八进制数可以通过在数的最高有效数前面添加GB 1988 IRV 0使其扩展到需要的长度l其结果按最高有效数字在前的方式写入字节流．各字段的解释如下所示：

    (1)c_magic包含由MAGIC(070707)定义的幻数字节，则把档案标识为可移动的档案。

    (2)c_dev和c_ino应包含唯一标识档案中的文卷的值（即不会有别的文卷具有相同的c_dev和c_ino值，但它们链接到同一文卷时除外）．这些值应以未规定的方式确定。

(3)c_mode应具有如表37中所定义的文卷类型和访问权限。

(4)c_uid应包含文卷主的用户ID。

    (5)c_gid应包含组的组ID。

    (6)c_nlink包含档案被创建时文卷的链接计数。

    (7)c_rdev包含由实现为字符特别文卷和块特别文卷定义的信息。

(8)c_retiree包含档案创建时文卷的最后修改时间。

(9)c_namesize包含路径名的长度。包括结尾的空字节。

(10)c_filesize包含文卷的以字节表示的长度．这是跟在首都结构之后的数据部分的长度。

 

表37  cpio中c_mode字段的取值

 

文卷权限

名    字

值

表示

C _ IRUSR

C _ IWUSR

C _ IXUSR

C _ IRGRP

C _ IWGRP

C _ IXGRP

C _ IROTH

C _ IWOTH

C _ IXOTH

C _ ISUID

C _ ISGID

C - ISVTX

000400

000200

000100

000040

000020

000010

000004

000002

000001

004000

002000

001000

    文卷属主读

    文卷属主写

    文卷主执行  

    组读

    组写

    组执行

    其他用户读

    其他用户写

    其他用户执行

    调整用户标识(uid)

    调整组标识(gld) 

保留

 

文卷类型

名    字

值

表示

C _ ISDIR

C _ ISFIFO

C _ ISREG

C _ ISBLK

C – ISCHR

040000

010000

0100000

060000

020000

目录文卷

FIFO文卷

普通文卷

块特别文卷

字符特别文卷

 

 

 

续表

名    字

值

表    示

C - ISCTG

C - ISLNK

C - ISSOCK

0110000

0120000

0140000

保留

保留

保留

 

10.1.2.2   cpio文卷名

    C_name包含文卷的路径名。该字段以字节为单位的长度就是c_namesize的值。如果在可能创建非法路径名的媒体上找到文卷名，实现应定义文卷中的数据是否存储在文卷层次中，并以什么名字进行存储。

    所有的字符都用GB 1988字符表示。为了在多种实现间获得最大的可移植性，名字应从可移植文卷名字符集中选择，字符为8位，最高有效位为‘O’。如果一个实现在文卷名、用户名及组名中支持使用可移植文卷名字符集以外的字符，那么，这些字符的一种或多种由实现定义的编码应被提供以用于交换的目的．然而格式读实用程序不应在一个不能通过本标准前面所描述的函数来访问的本地系统上创建文卷名，见open()、stat()、chdir()、fentl()和opendir()．如果文卷名在可能会创建无效文卷名的媒体上找到，实现应定义文卷中的数据是否存储在本地文卷系统中，以及以什么名字进行存储．格式读实用程序可以选择忽略这些文卷，只要它产生指示文卷正被忽略的错误。

10.1.2.3  cpio文卷数据

    跟在c - name字段之后，有c_filesize个字节的文卷数据．将以与文卷有关的方式解释这些数据。如果c_filesize为O，那么，在c_filedata中将不会有数据。

10.1.2.4  epio特殊项

    FIFO特别文卷、目录和档案尾部’c_filesize都等于0。对于其他的特别文卷，本标准未规定c_filesize。在前一个文卷表项的最后一个字节之后直接写入档案中下一个文卷表项的首都。指示文卷名为“TRAILER l l J”的首都应指示档案的结束I档案的最后一块中，跟在这个首部之后的内容是未定义的。

10.1.2.5  cpio值

    表37中描述了cpio档案格式所需的值。

    遵循本标准的系统上应支持C_ISDIR,C_ISFIFO和C_ISREGI前面定义的其他值是为与现存系统的兼容而保留的。还可以支持其他的文卷类型，但这些文卷最好不写到打算移动到可移植的系统中的档案中。

    本标准保留了C_ISVTX、C_ISCTG,C_ISLNK和C_ISSOCK，以获得同现存的实现的兼容性。

    当从档案中恢复文卷时：

    (1)如果用户不具有创建指定类型文卷的适当权限，则格式解释实用程序忽略此项，并发出错信息到标准错误输出上。

    (2)只有普通文卷具有要恢复的数据。假定一个普通文卷满足用户施加于格式读实用程序的任何选择准则，这样的数据将被恢复．

    (3)如果用户不具有设置一个特定的方式标志的特权，该标志就应被忽略．档案格式的某些方式标志在本标准的任何地方都没有提到过．如果实现不支持这些标志，则这些标志可被忽略。

10.1.2.6 参阅

    <grp.h>，见9.2.1条；<pwd.h>，见9.2.2条；<sys/stat．h>，见5.6.1条；

    chmod()，见5.6.4条clink()，见5.3.4条；mkdir()，见5.4.1条；

    read(),见6.4.1条~stat()，见5.6.2条。   

10.1.3 多卷册文卷

    由档案格式和交换文卷格式表示的数据存在于多个文卷中，这种情况是可能的．

    格式被看成是一些字节流．文卷结束（或等价于媒体结束）条件可以发生在逻辑字节流的任意两个字节之间．如果这种条件发生，跟在文卷尾的字节将是下一个文卷的第一个字节．格式读实用程序以实现定义的方式决定下一个该读的是哪个文卷。

 

附录A

参  考  文  献

（参考件）

本附录包括了相关的开放系统标准以及以往的实现和应用程序编程方面的建议的读物。

 

A1  相关的开放系统标准

A1.1  网络标准

{B1}GB 9387--88,信息处理系统  开放系统互连  基本参考模型

{B2}GB 12453--90,信息处理系统  开放系统互连  运输服务定义(IS0 8072)

    {B3}GB 12500--90,信息处理系统  开放系统互连  面向连接的运输协议规范(IS0 8073)

    {B4} IS0 8326 : 1987, Information processing systems--Open Systems Interconnection

     --Basic connection oriented session service definition

    {B5}IS0 8327:1987,Information processing systems--Open Systems interconnection--Basic con-nection or iented session protocol definition

    {B6}ISO 8348, 1987, Information processing systems--Data communication--Network servicedefinition

    {B7}IS0 8473 : 1988, Information processing systems--Data communication--Protocol for provid-ing the connectionless-mode network service

    {B8}IS0 8571: 1988, Information processing systems--Open systems interconnectiori--File,Access and Management

    {B9}IS0 8649 : 1988, Information processing systems--Open Systems Interconnection--Service

definition for the Association Control Service Element

    {B10}ISO 8650 : 1988, Information processing systems---open systems Interconnection--Protocolspecification for the AssociationControl Service Element

    {B11}IS0 8802-2 : 1989 (IEEE Std 802. 2--1989 ANSI), Information piocessing systems--Localarea networks--Part 2 ,Logical link control

    {B12}IS0 8802-3 : !989 [IEEE Std 802. 3 -- 1988 (ANSI) ], Information processing systems--Localarea networks--Part 3, Carrier sense multiple access with collision detection (CSMA/CD)accessmethod and physical l~yer specifictions

    {B13}ISO/IEC 8802-4 : 1990 [IEEE Std 802. 4--1990 (ANSI)l, Information technology--Localarea networks--Part 4-Token-passing bus access method and physical layer specifications

    {B14}IS0 8802-5:…(I'EEE 802. 5--1989),Information technology--Local area networks--Part5:Token ring access method and physical layer specifications

    {B15}IS0 8822 : 1988, Information processing systems--Open Systems Interconnection--Connec-tion oriented presentation service definition

    {B16}ISO 8823,1988, Information processing systems--Open Systems Interconnection--Connec-tion oriented presentation protocol specification

    {B17}IS0 8831: 1989, Information processing systems--Open Systems Interconnection--Job

transfer and manipulation concepts and services

    {B18}ISO 8832 : 1989, Information processing systems--Open Systems Interconnection--Specifi-cation of the basic class protocol for job transfer and manipulation

    {B19}CCITT推荐x.25,Interface between data terminal equipment(DTE) and data circuit-ter-equipment(DCT) for terminals operating in the packet mode and connected to public datanetworks by dedicated circult    Data link set-

    {B20}CCITT推荐X. 212,Information processing systems--Data communication—Data link service definition for open systems interconnection

A1.2  语言标准

    {B21}GB 3057--82 程序设计语言  FORTRAN

    {B22}GB 4092  程序设计语言  COBOL

    {B23}IS0 8652 1 1987 程序设计语言  Ado

    {B24}ANSI X3. 113--1987  Information systems--Programming language--FULL BASIC

    {B25}ANSI/IEEE 770X3. 97--1983,Standard pascal Computer programming Language

    {B26}ANSI/MDC Xll. 1--1984,Programming Language MUMPS

A1.3  图形标准    功能描述

    {B27}GB 9544-88，信息处理系统计算机图形图形核心系统(GKS)的

    {B28}ISO 8632:1987, Information processing systems--Computer graphics -Metafi|e for thestorage and transfer of picture description information

    {B29}ISO/IEC 9592sI989,1SO/IEC 9592tI989(ANSI X3. 144--1988),

    Information processing systems--Computer graphics--Programmeds hierarchical interactivegraphics system(PHIGS)

A1.4  数据库标准

    {B30}IS0 8907:1987 ,Database Language--NDL

{B31}IS0 9075:1987 ,Database Language—SQL

 

A2  其他标准

    {B32}ISO 639:1988,Code for representation of names of languages

{B33}ISO 3166:1988,Code for the representation of names of countries

{B34}ISO 8859-1:1987,Information processing -8-bit single-byte coded graphic character sets--Part l :Latin alphabet No.1

    {B35}IS0 9127:1988,Information processing systems--User documentation and cover information for consumer software packages  

    {B36}ISO/IEC 9945-2.…,Information technology--Portable operating system inte1(POSIX)--Part2-Shell and utilities

    {B37}ISO/IEC 10646-'" ,Information processing--Multiple octet coded character set

{B38}IEEE Std 100--1988,1EEE,Stsndard Dictionary of Electrical and Electronics Terms

 

A3  以往的文卷和工业文本

 

    所有UNIX的以往实现的始祖是Multics系统

    ·Organick,Elliot l·,The Multics System:An Examination of Its Structure,The MIT Press,Cambridge, MA( 1972)。

    关于以往的实现的最基本和最有影响的文条是

    ·Ritchie, D. M. and Thompson, K. ,"The UNIX Time-Sharing System,'Commu·ACM7 (7) pp. 365-375 Association for Computing Machinery, (July 1974)4

    这是依赖UNIX的第一篇论文．它描述UNIX第六版(V6)。

    ·Ritchie,D. M. and Thompson,K. ,"The UNIX Time-Sharing System , "Bell System Technical Journal 57 (6 part 2)pp. 1905--1929 American Telephone and Telegraph Company, (July-Auguest1978).这是经过修改的文条,它描述UNIX第七版(V7)。

      UNIX第七版手册是

    ·AT&T,UNIX Time Sharing System.UNIX Programmer's Manual Seventh Edition,Bell Tele-phone Laboratories ,Inc. ,Murray Hill,New Jersey(January, 1979).

    ·Ritchie,Dennis M. ,"The Evolution of the UNIX Time-Sharing System,"AT&T Bell I.aborato-ries Technical Journal 63 (8) pp. 1577--1593 American Telephone and Telegraph Company, (0ctober 1984).

    · Ritchie, Dennis M. , "Reflections on Software Research', Commun. ACM 27 (8) pp.. 758—760 Association for Computing Machinery, (August 1984). ACM图灵奖演讲.

    ·Ritchie, Dennis M. ,"UNIX" z A Dialectic , "Winter 1987 USENIX Association Conference Pro-ceedings ,Washington ,DC ,pp. 29-- 34USENIX Association ,P. 0. Box 2299, Berkeley ,CA 94710, (21-23January 1987).

关于该系统的一组重要的文章可从

    ·BSTJ,"UNIX Time-Sharing System,"Bell system Technical Journal 57 (6 Part2) American Telephone and Telegraph Company, (July-August 1978)

    ·BLTJ,"The UNIX System,"AT~T Bell Laboratories Technical Journal 63 (8 Part 2)American Telephone and Telegraph Company, (October 1984) qa找到.

      UNIX System Ⅲ手册是

    ·AT&T,UNIX SystemⅢProgramming’s Manual,Western Electric Company,Inc. ,Greensboro,N. C (0ctober, 1981 ).

      SVID

·AT&T,System V Interface Definition,Lssue 2,and 3,AT&T(1986) ,1989.

      UNIX system V的实现在

    ·Bach ,Mauriee J. ,The Design of the UNIX Operating System,Prentice--Hall,Englewood Cliffs,New Jersey(1987)中描述.

    4.3BSD手册

·UCB-CSRG,4.3 Berkeley Software Distribution,Virtual VAX-11version ,The Regents of the University of California,Berkeley,California(April 1986).

    4.3BSD核心的实现在

    ·Quarterman, John S.，Silbersdhatz, Abraham,and peterson, James L. , "4.2BSD and 4.3BSD as Examples of the UNIX System,"ACM Computing Surveys 17(4)pp. 379-418 Association for Computing Machinery, (December 1985).

·Leffler, SamuelJ. , Mckusick, Marshall kirk, karels, Michael L. ,Quarterman, John S. ,and Stettner,Armando,The Design and lmple-mentation of the 4.3 BSD UNIX Operating System, Addison-Wesley, Reading, Massachusetts (1988)中描述.

 

A4  C语言参考资料

 

    有关C语言以往情况的基本参考文献是：

    . Kernighan, Brian W. and Ritchie, Dennis M., The C Programming Language, prentice-Hall, En-glewood Cliffs,New Jersey(1978).

    ．有关C语言程序设计方面有用的辅导资料是：

    . Harbison, Samuel P.and Steele, Guy L.,C:A Reference Manual, Prentice-Hall, Englewood Cliffs, New Jersey( 1987).

 

A5  以往的应用系统程序设计辅导资料

 

    特别需要留意的（不一定适合于初学者）一本书是：

    . Kernighan, Brian w. and Pike, Rob, The UNIX Programming Environment, Prentice-Hall, Inc.，Englewood Cliffs ,New Jersey(1984.).

    针对BSD系统较为详细的资料是：

    . Megilton, Henry and Morgan, Rachel, Introducing the UNIX System, Mcgraw-Hill (BYTE Books),New York(1983).

    较新的一本是：

.Rochkind,MarcJ.,Advanced UNIX Programming,Prentice-Hall,Englewood Cliffs, New Jersey(1985)。

 

A6  有关的标准

 

/usr/group Standards Committee. 1984/usr/group Standard.

Santa Clara ,CA zUniiorum, 1984.

X/Open Company,Ltd. X/Open portability Guide,

Issue 2. Amsterdam :Elsevier Science Publishers, 1987。

X/Open Company,Ltd. X/Open portability Guide,

Issue3. Englewood Cliffs: Prentice-Hall, 1989。

 

附录B

依据和注释

（参考件）

 

    本附录的目的是为了有助于回顾。它包含了与本标准内容相联系的历史资料和说明了包括或放弃一些特性的原因。它也包含了应用程序员在所推荐的编程实践中感兴趣的注释，重点在于标准中不能马上明白的某些方面的推论。

 

Bl  概论

 

B1.1  范围

    本附录主要集中在为导出本标准而对UNIX系统所做的增加、澄清和修改。从整体来看，它不是UNIX系统的原理，因为POSIX.1制定者的目标是整理已存在的实践，而不是设计一种新的操作系统。在本附录中不想定义以前已有的UNIX系统的结构。正如在基本文档中所整理的，它主要从此处所解释和证明的实践出发。

    超出本标准范围的或本标准未涉及到的材料，都隐含为“未规定的”。它可以被包含在实现中，因此实现必须为此提供一个规格说明。术语“实现定义的”在本标准中有一种特定的含义，并不是“由实现定义的（或规定的）”的同位语。

    本附录讨论了一些没有被采纳进本标准里的UNIX系统特性．这些特性中的许多特性在某些U NIX系统的实现中是很流行的，以至那些实现的用户会问为什么它们未在本标准中出现。希望本附录能给用户提供适当的答案。

    对于界面规范的一些细节，本标准允许作选择，其中的一些是本标准规定的可选项子集-见B2.9条。

    虽然本标准提供的服务已用C语言定义了，但是提供基本的、标准化服务的概念却最好不只限于一种特定的编程语言的程序。以另外的编程语言实现界面的可能性产生了术语。具有C语言协约的本标准”。词“协约”表示二组概念上的服务以及一种为了访问这些服务而建立的规则和语法的标准化的C语言界面。预料将来的国际标准会把C语言协约与本标准的独立于语言的服务分离开来以包含对其他编程语言的协约。

    C语言标准是独立于编程语言的核心服务的功能定义的基础。本标准可以认为是C语言的协约。从第1章到第7章及第9章中，大致地对应于标准中独立于编程语言的核心服务的C语言的实现，第8章反映了C语言的特殊部分。

    用来选取独立于编程语言的核心服务的准则也许与所期望的不同。这种核心服务表示了可能形成本标准语言协约的那些编程语言公共的服务——最公共的特性，不是选取来反映一个理想的操作系统的最重要的系统服务。因此，一些基本的系统服务没有被包含在独立于语言的核心中。举例来说，存储管理程序初看起来似乎是一种核心服务——它们是绝对基本的系统服务。然而由于编程语育如FOR-TRAN传统地不提供存储管理，因此存储管理程序必须包含在本标准语言的专用部分巾。把存储管理归类为一种核心服务将对FORTRAN的实现强加一些不合理的要求。

    传统上支持存储管理的任何编程语言将在他们的协约的依赖于语言的部分中包含那些存储管理程序。以后某个时候将对功能分类进行标准化，如果那些功能针对某种语言已经像传统那样实现，则这些功能必须包含在语言协约的依赖于语言的部分中。可以确信，某些关键功能，例如存储管理的分类将不会从任何可用的语言协约中排除．见B1.3.3条。

    本标准和本附录都不是所规定的界面使用的拓导。然而在附录A的A3章中包括了一些有关UNIX系统历史的参考资料。

B1.1.1  本标准和C菇言标准

    有些C语言的函数和定义由本标准处理，但大多数由C语言标准处理。最一般的准则是本标准负责操作系统的专用函数，而C语言标准定义了C的库函数。见B2.7条和B8。

    这两个标准在基本原理上不相同的领域是：

    (1)函数参数类型表。这些出现在C语言标准的语法中。在本标准中参数表按函数的原型落申。作出这种改变有两个起因。其一是C语言标准的使用将会迅速推广，因此这不会存在什么问题；其二是实现者用本标准没有提供指导的某些函数原型会有困难（提供限定符const是很困难的。）为了能转换到通用C语言，本标准中仍保留一些专用的指导和权限。

    (2)单进程及多进程。C语言标准规定了一种在单进程操作系统上使用的语言，并作为操作系统或者其他独立程序实现的独立基础。但是本标准界面是一个多进程分时系统的界面。因此本标准必须在C语言标准完全没有提到进程的地方考虑到多进程，例如kill()。见B1.3. 1.1条。

    (3)单操作系统及多操作系统环境。C语言标准规定了一种可用于多个操作系统的语言．因此它具有剪裁自己以适应特殊的现行环境的能力，本标准是一个操作系统的界面规范，依照定义它也仅仅涉及到单一的操作系统环境，尽管它已被小心地按照各种基本的操作系统写成为广泛可实现的（见“引言”中“广泛可实现的”）。见B1.3.1.1条。

    (4)编译环境及执行环境。本标准主要涉及C语言标准的执行环境，而把编译环境留在C语言标准中。见B1.3. 1.1条。

    (5)与独立的实现相对比的宿主实现。所有本标准的实现在c语言标准的意义上是宿主实现，同样可见“引言”中有关遵从性的说明。

    (6)文本文卷方式及二进制文卷方式。c语言标准对一个文卷定义了文本和二进制两种方式。但本标准界面和与之相联系的以往的实现没有做这样的区分，并且所有由本标准定义的函数在处理文卷时好像这些方式是一样的（最好不说本标准文卷不是正文的就是二进制的文卷）。c语言标准编写了它们的定义使得区分是可能的。尤其是文本方式文卷不要求行分隔符结尾，这也意味着它们不要求包括行分隔符。

    进而，伴随c语言标准的附录和本附录之间方法上有根本的不同。c语言标准的附录是一个单独的文档，它几乎涉及了与c语言标准的基本文档不同的所有变化，这些基本文档通常是kernighan和Ritchie或1984/user/group标准(见A3）。本附录不能这样做，因为操作系统界面比c语言有更多的变型。这个不同最值得注意的方面是c语言标准的附录说明了来自基本文档的“平稳的变化(QUIETCHANGES)”。本附录不包括这样的说明，因为来自一个以往的实现的平稳的变化可能精确地相应于另一种以往的实现，而且针对于已存在的另一个实现所编写的应用程序来说可能非常值得重视。

B1.1.1.1  本标准独有的函数

    这些从操作系统环境返回参数的函数是；ctermid()、ttyname()和issatW()。

    函数fileno()和Idopen()在C语言的流指针和本标准的文卷描述字之间建立映象。

B1.1.1.2  C语言标准中独有的函数

    有许多对于操作系统界面有用的并且是为遵循本标准所要求的函数，但它们恰是c语言的一部分。这些函数在8.1条中列出，其中．也说明了这些函数是由本标准和c语言标准一起定义的。某些由c语言标准定义的术语在本标准的2.7条中采用。

    有一些例程太专业化，因而不能包括在标准中。这些例程包括bsearch()和qsort()。

B1.1.1.3  既不是本标准中也不是C语言标准中的函数

    当考虑国际标准字符集时，有一些函数被认为是临界的和有疑问的：一toupper()．一tolower()、toascii()和isascii()。

    虽然malloc()和free()在c语言标准中，并且由本标准的8.1条所要求，但是这两个标准都不包括brk()和。brk()（尽管它们包括在1984/user/group标准中）。这是因为本标准的设计目的是要为编写遵循本标准的应用程序提供所要求的一组基本函数，依赖于基础的实现的malloc()或free()．对于本标准来说是不适当的。

Bl.l.l.4  由本标准做基础，C语言标准作为附加

    因为C语言标准不依赖于本标准，所以这部分没有内容．

BI.1.1.5  C语畜标准为基础，本标准附加

    如果仅仅因为测定变量是得知某些数学函数何时失败的唯一方法，那么c语言标准必须定义errno。但本标准在更广泛的范围里使用它，并在2.4条中为它增加了某些语义，也为它定义了某些值。

    许多由c语言标准所用的数值限定值在2.8条中由本标准采纳，并且增加了一些新的项．所有这些可在前导文卷<limits.h>中找到。

    c语言标准提供了signal()，一种用于中断的最小功能。本标准用更精心定义的机制来替换它，此机制用于多进程，且当信号来自外部的源时更加可靠。

    函数time()由C语言标准使用，但本标准进一步规定了时间值。

    在2.6和3.1.2条中引用的函数getenv()也是由C语言标准定义的。

    扩展了函数rename()．进一步规定当新的文卷已经存在或任一实参表示目录时的行为。

    函数setlocale()和时区的处理作了进一步规定以获取本标准环境的优点。

    标准1/0函数按它们与文卷描述字的关系和多进程之间的关系作了规定。

B1.1.1.6  与C语言标准和本标准都相关的函数

    c语言标准中的“符合”的定义和本标准中的“遵从性”的定义相类似，尽管后者注明了一些潜在的硬件限制。

    本标准在2.2.2条中定义了一个可移植的文卷名字符集，它就象c语言标准的标识符字符集那样，可是，本标准并不允许大、小写字符是相同的．见2.3.4条中文卷名可移植性．

    函数exit()仅由c语言标准定义，因为它涉及到关闭流，这个课题如同函数fclose()本身那样，几乎完全由c语言标准定义。但本标准定义了函数一exit()，其中也增加了关于函数exit()的语义。这样也就允许本标准不用引用C语言标准的函数atexit()。

本标准定义了I/ill()-而c语言标准定义了raise()，它们是相似的，只是raise()中没有实参进程ID，因为由C语言标准所定义的语言没有引入多进程的观念。

新增加函数sigsetjmp()和siglongjmp()以提供与c语言标准的函数setjmp()和longjmp()相似的功能，并且它可附带地保存和恢复信号状态。

Bl.2  引用的正式标准

    本条中没有提供附加的依据。

Bl.3  遵从性

    这些遵从性定义是从早期草案的遵从的实现、遵从的应用和遵从的可移植的应用转换来的。但在以下三个方面变得更清楚了：

    (1)在扩展、任选和限制之间的关系；

    (2)三个遵从性术语之间的关系；

    (3)本标准和C语言标准之间的关系。

Bl.3.1  遵从性实现

    这些定义可使应用程序开发人员知道在一个实现中可依赖什么。

    本标准没有对严格遵循本标准的实现作定义；因为这样的实现仅能提供本标准规定的设施而不能有任何扩展。而一个没有系统管理和初始化设施的实际的操作系统是不存在的，但这些设施超出了本标准的范围。

Bl.3.1.1  要求

    宁用单词“支持"(support)而不用“提供”(provide)，目的是，允许一个没有常驻软件开发设施的实现’但这种实现支持严格遵循本标准的应用程序的执行，成为一种遵循标准的实现，见B1.1.1条。

B1.3.1.2  文档编制

    POSIX遵循标准的文档使用与本标准相同的编号结构以适应交叉查找。这种要求符合并补充了由别的P0SIX工作小组开发的验证测试格式。一种实现所选取的所有可选项，应反映在前导文卷<limits.h>和<unistd.h>中。

    注意，实现可以改变遵从性文档记录中术语“可以(may)”的使用，它隐含着不要求描述那些标记为未定义或未规定的特性。

    为了适用，购置者必须考虑系统的其他方面。许多系统采用缓冲设施，它维护在易失存储器中的更新的数据并异步地向非易失存储器传送。各种异常的条件，如断电或系统发生故障，都可以引起已修改的数据丢失。这些数据可能与一个仍然打开的文卷、一个已经关闭的文卷、一个目录或者其他与永久存储器相联系的一些内部系统数据结构有关。因为这些数据可能全部或部分地丢失，因此，只有仔细核对文卷的内容才能确定没有发生数据的更新。

    同样．相关的文卷活动，在这些活动中多个文卷和／或目录被修改或在文卷系统结构中，空间被分配或释放，可能造成在各种文卷和目录中或在文卷系统自身中数据关系的不一致。这种不一致性可能破坏应用程序按所期望的顺序发生的更新，所以在一个地方的修改要对应于在另一地方相应的修改。

    例如，如果一个用户创建一个文卷，，把信息放在文卷中，然后在另一个文卷中记录下这个动作，那么这时系统或电源发生了故障，随后又重新启动，就可能导致这样的状态即记录动作的状态被永久地记录下来，但所创建的文卷（或它的某些信息）却丢失了。这样造成的后果对于用户来讲．是随机的．在这样的

系统中保障用户安全的唯一做法是要系统管理员，在系统或电源发生故障之后，整个文卷系统必须从最近的后援副本重新恢复（但自建立此后援副本之后，所做工作的结果丢失）。

    每个实现在这方面的性能可能各不相同，并且可以满足也可以不满足一个特定的应用程序或用户的要求。对这样的情况提出强制性的规定超出了本标准范围。一种实现对于影响到数据或序列丢失的发现能提供什么样的设施，同时提供什么样的基本实现技术和／或设施来限制或减少这种丢失及其后果，这些由购买者负责决定。

B1.3.1.3  遵从性实现的可选项

    本标准中有一些符号常量（若被定义的话），指示这些可选项是启用的．其他的符号常量是因为别的原因而存在于本标准中的。这部分放在本标准中是用来帮助理解哪些常量是真正与“可选项”有关的，而哪些是更与不同系统的行为有关。

    为了适应以往的实现，这些实现在一定的情况下，有不同的语义，但它们之间不能明显地确定哪一种更好，在这种情况下本标准允许在两种可选项中任选一种时使用词“可以(may)”来表示。应制订开发测试标准的工作组的请求，改成由带标志的正式可选项来规定．当标准的开发者的目的是允许其中任一种（在某些情况下为两种）行为遵循本标准，并要求应用程序对任一种选择都要适应的情况下，很明显这些就作为可选项由购买者选择了。因此，这些可选项被取消了，而引入短语“一个实现可以任选(An im-plementation may eithe，)”来代替该可选项。在这个短语被使用的地方，指出了一个应用程序须适应两个中任何一个行为。

    本标准制定者的主张是所有遵循本标准的应用程序都要适应两种行为中的任何一个，只有在最例外的环境（由技术需要决定）下应由购买者规定唯一的行为。向后兼容性没有加以特殊考虑，因为这与标准的目的：提倡应用程序的可移植性（和可移植应用程序开发）不相容。

    一个应用程序可以用以下两种办法来适应这些行为。一种是忽略这些行为之间的区别（如果它们与应用程序不相干的话）或者采取一种动作以保证处在一种已知状态。在某些实现中这些动作可能是多余的。

    验证程序（在这种意义上的应用程序），能或者报告发现的实际结果，或者只是忽略区别，把任何一种可接受的行为作为一个错误对待的情况是不存在的。这可能使验证稍微复杂一些，但与行为方面允许变化的目标更一致。

    在某种环境下，行为可能随给定的进程变化。例如，在联网文卷系统存在的情况下。不管·与··是否在目录中，行为可以随正在搜索的目录而变化，而且如果允许，但并不要求，这些目录项在一个目录中存在，程序才可能是可移植的。

    在类似这种情况下，找到·和··简单地忽略它们往往比确定是否需要它们更容易。

B1.3.2  遵从性应用

    这些定义指导用户或应用程序的采用者决定，在什么样的实现上，一个应用程序能运行；或要在另外的实现上运行，要做多少修改。有关遵循标准的应用的三个定义是模仿c语言标准中相应的定义的。

    本标准偶然使用术语“可移植应用程序(portable application)”或“遵从的应用程序(comforming application)”。当使用它们时，便是三个遵从性术语中的一个的同义语。这三个遵从性应用的区别与其他标准的要求有关，或在使用扩展的遵循本标准的应用情况下与所实现的扩展有关。当使用其中一个不太正式的术语时，很明显在讨论的上下文中，更为正式的名字要合适些。

B1.3.2.1  严格遵循本标准(POSIX.1)的应用

    这个定义类似于C语言标准的遵从的程序(conforming program)，严格遵循本标准的应用和严格遵循C语言标准的应用程序(Strictly Conforming POSIX.1 Application和Standard C strictly Con-forming Program)之间的主要区别是后者不能使用在c语言标准中没有的本标准的功能。

B1.3.2.2  遵循本标准CPOSIX.1)的应用

    <National Bodies)的例子包括美国标准ANSI、英国标准BSI和法国标准AFNOR。

B1.3.2.3  使用扩展的遵循本标准(POSIX.1)的应用

    由于配置可能的要求，或由于实现的特性超出了2.8条中的规定，或者由于与硬件有关（例如，数组的长度或文卷空间），使得不是每个“使用扩展的遵循本标准(POSIX．1)的应用”都可以在每个遵从的实现上运行的。

B1.3.3  针对C编程语言依赖于语言的服务

    由于历史原因，本标准既是一个操作系统界面的规范，又是针对该规范的C语言的协约。

    很明显，这两方面必须分离成两个单独的实体，但由于标准获得批准的紧迫性，而且由于C语言是类似于UNIX系统的那种系统事实上的基本语言，使得标准目前的做法是必要的也是可行的。

    因此，在把规格说明与当翦的协约分开之前，将对C之外的语言协约做工作。除C语言之外的其他 语言的语言协约不能完全按照C语言的协约来仿造，并且最好不选择C语言特有的东西。

    在本标准中功能重复的部分[例如，函数open()和treat()，是没有理由把这种重复带到别的语言中的。另一方面，一些语言已经有基本上与本标准所提供的相同的功能。在这种情况下，在本标准的功能和那个语言的功能之间做些变换比模拟C语言的协约是一种更好的选择。

    由于C语言没有I/O的语法，而在本标准中I/O是一大组成部分，所以本标准中已使用了一些I/O函数。这些函数对于其他语言可能不适合。例如．FORTRAN的REWIND语句可以作为映象到函数lseek()的一种特殊情况的一种选择，而它的SEEK语句可以完全复盖函数lseek()。如果是这种情况，就没有理由对于同样的功能提供另外的“子例程”。在更一般的情况中，文卷描述字和FORTRAN的逻辑设备号可以是一种有用的映象．在I/O操作中FORTRAN的“ERR=”任选可以代替返回值“-1”；整个出错的概念可以采用不同的处理。

    像对C语言所做的那样，对于其他语言来说，对基本语言标准未定义或未规定的某些领域作规定，或允许它们作为扩展不是没有理由的。而且，事实上可能解决一些困难问题。

    在语言协约中，尽可能多地使用目标语盲增强了可移植性。如果一个程序希望使用本标准的某些功能，而这些功能是与语言语句相联系，而不是作为另外的过程或函数调用出现，而且使用这些函数时这个程序事实上遵循语言标准。那么程序可移植到那样的系统上，其范围比专门为使用本标准的协约而引进的过程和函数调用以便完成同样事情的系统大。

    一个程序如果需要本标准的功能而这些功能又不是直接与标准语言（如上面的）相联系，则这样的程序在本标准环境之外不是可移植的。扩展是否是语法上规定的或是一个新函数都无关紧要；不经过努力它仍然是不可移植的。在这种情况下，在确定怎样更好地把本标准的功能映象到一个特殊的语言协约中时，不考虑语言扩展似乎是没有道理的。例如，一个类似于READ的新语句，它装入来自一个像函数stat()的调用的值，或许是把象在C语言中返回的结构那样的数据读到FORTRAN变量表中的最好解决方法。

    不要企图去仿造一个printf()或者scanf()（或者C语言标准的其他函数），但是，在语言中最好使用与之等效的函数。(例如，FORTRAN的格式READ和WRITE，Pascal中的read/readln和write/writeln。)

    在操作系统标准和语言标准之间存在着固有的特殊关系。其他类型的标准（例如图形）直接对通用语言的语句有这么多的协约是不太可能的。然而，操作系统标准最好提供语言所要求的服务。当创建协约时，只使用新的函数和过程这种自然的趋势需要小心地审查。（在所有情况下一…对应的协约或许是不可能的，但本标准第8章中的标准I/O这样一些协约是可能的。）

    直接联编到语言，可能的话，最好尽可能使用操作系统和自然存在语言之间的直接映象{在合适的地方，把语言要求改成对操作系统的要求以便促进这样的映象，这两者都是应当鼓励的。（将来包含一种截断功能是一个很好的例子，此功能特别是针对FORTRAN的ENDFII。E语句，但也是通用的。）

    显然，创建一个协约的一部分工作是为引入的函数选取名字，并使所选取的这些名字对于该语言来说是适当的。可能不使用最受限制形式的名字，因为正如前面讨论的，使用这些函数会使应用程序不能移植到不是本标准的系统上，并且如果遵循本标准的系统接受最低公共命名系统所不接受的名字，则就没有理由事先排斥这样的名字。（具体的例子是c语言，在c语言中对于"non—UNIX"系统，限定外部标识符为六个字符。）

B1.3.3.1  遵从性的类型

    在本条中没有提供附加的依据。

B1.3.3.2   C语言标准中依赖于语言的系统支持

    “名字空间污染一问题需要联系上下文来理解。见B2.7.2条。

B1.3.3.3  通用C语言中依赖于语言的系统支持

    “名字空间污染一问题需要联系上下文来理解。见B2.7.2条。

B1.3.4  其他有关于C语言的规格说明

    有关使用库函数的信息是从c语言标准中的描述改编来的。这里有一个例子，说明应用程序如何不让自己成为可以是宏，也可以不是宏但不是真正的函数的库函数。

    函数atoi()可以按下列方法之一来使用；

    (1)和与相联系的前导文卷一起使用（可能产生宏扩展）

    # include <stdlib．h>

    /*…*/

    i=atoi(str);

    (2)和与相联系的前导文卷一起使用（一定产生一个真正的函数调用）

    # include <stdlib．h>

    # under atoi

    /*…*/

    i=atoi(str)；

    或

    # include (stdlib．h)

    /*…*/

    i=(atoi) (str)；

    (3)通过显式声明

    extern int atoi (const char*)；

    /*…*/

    i=atoi (str)；

    <4)通过隐含声明

    /*…*/

    i=atoi(str)；

    （假设在这个范围内没有函数原型。在c语言标准中具有可变的实参的函数是不允许的；而且，在这种情况下，实参类型转换的扩展是受不同规则支配的）。注意，c语言标准为编译程序保留由“--”打头的名字．因此，编译程序能实现一个，例如，内部固有的函数_asm_builtin_atoi()，它可被识别并且可被扩展为直接插入的汇编码。在前导文卷(stdlib.h>中，可能是下面这样：

    # define atoi (x)_aam_builtin_atoi (x)

    用户“正常”地调用函数atoi()，然后被扩展为直接插入的汇编码i但是，当应用程序需要时，例如，它把函数的地址存放在一个函数指针变量中时，实现者应能提供名为atoi()的可调用函数。

B1.3.5  其他有关于语言的规格说明

    在本标准系统上对于所有语言，包括c语言，支持标识符“long”和大小写链接．句子中包含有关“如果这样的扩展是”部分以便允许有绝对的最大值或允许大小写不区分的绝对要求的语言遵循本标准。

    由于下列要求而需要包括更长的名字：

    (1)很多类似于本标准的系统已经是一致的。

    (2)许多现存的语言标准限制文卷名的长度以适应现存的系统，这些系统不可能为了更长的文卷名而作修改。然而，由于其他原因不能期望这些系统遵循本标准。

    (3)许多以往的应用程序依赖于这样较长的名字。

    (4)将来的语言(例如FORTRAN 88)可能要求更长的名字。

  具体到FORTRAN 77，此标准允许长名字，本标准要求在本标准上运行的FORTRAN实现支持长名字。区分大小写和长度的要求认为是正交的，但若语言允许这两者，则此两者都是要求的。注意，因为为了编写一个有用的程序，应用程序并不需要超出该语言标准，所以即使不存在该语言协约，它也可以遵循本标准。

    这种要求允许在本标准对语言，比如FORTRAN的协约中使用合理长度的名字。很清楚，不会禁止与最小的FORTRAN一致的程序在本标准上编译和运行。

    因为它是执行环境的一种规格说明，所以正是在本标准限制的内部规定了与语言一致的语言处理程序与链接程序的行为。这与GKS那样的软件包不同，这种软件包可以理所当然地预料被移植到迫使语言最小化的系统中。

    似乎会引起下面的争论：为什么此规格说明对于公共的POSIX语言协约委员会是适当的而不专门针对本标准。此争论忽略了这样的目的，该目的是要求链接程序和别的处理“目标码”（此概念尚未在本标准中正式定义）的程序能够支持长名字．这种横跨所有语言的要求应属于标准的规格说明而不局限于任何一种语言。注意，这也有点随意性，在那里如果语言不能处理长名字，那么就允许不要求长名字，但却平息了“加载程序不允许长名字，所以[一种具体的]语言协约不应迫使这样做”的争论。

    针对给定语言的一种严格遵循的应用程序不能使用针对该语言（而不是基本操作系统）超出本标准的任何扩展。如果一种应用程序使用了此语言的本标准协约所提供的附加的界面遵循该语言，则它严格遵循本标准