您正在查看: 标签 数据类型 下的文章

Field (ADO/WFC Syntax)

Field (ADO/WFC 语法)

包 com.ms.wfc.data

方法

public void appendChunk(byte[] bytes)
public void appendChunk(char[] chars)
public void appendChunk(String chars)

public byte[] getByteChunk(int len)
public char[] getCharChunk(int len)
public String getStringChunk(int len)

属性

public int getActualSize()

public int getAttributes()
public void setAttributes(int pl)

public com.ms.com.IUnknown getDataFormat()
public void setDataFormat(com.ms.com.IUnknown format)
(For more information, see the Microsoft Visual J++ WFC Reference documentation for the com.ms.wfc.data.IDataFormat interface.)

public int getDefinedSize()
public void setDefinedSize(int pl)

public String getName()

public int getNumericScale()
public void setNumericScale(byte pbNumericScale)

public Variant getOriginalValue()

public int getPrecision()
public void setPrecision(byte pbPrecision)

public int getType()
public void setType(int pDataType)

public Variant getUnderlyingValue()

public Variant getValue()
public void setValue(Variant value)

public AdoProperties getProperties()

Field Accessor Methods

Field 对象的 Value 属性可获得或设置该对象的内容。内容以变体型表示可被指定值和任何数据类型的对象类型。

ADO/WFC 使用 getValue 方法和 setValue 方法实现 Value 属性,前者返回变体型对象,后者则把变体型视为参数。虽然在某些语言(如 Microsoft Visual Basic) 中变体型的效率已经很高。但仍可以在 Microsoft Visual J++ 中通过使用本地 Java 数据类型获得更高的性能。

Value 属性外,ADO/WFC 还提供使用 Java 数据类型获得并设置 Field 对象内容的 accessor 方法。大多数这些方法都具有名称,其形式为 GetDataType 或 SetDataType。

有两点例外须加以注意。getObject 方法之一可返回强制为指定类的对象;不存在 getNull 属性。但 isNull 属性是存在的,它返回的布尔值可指明字段是否为空。

public native boolean getBoolean();
public void setBoolean(boolean v)

public native byte getByte();
public void setByte(byte v)

public native byte[] getBytes();
public void setBytes(byte[] v)

public native double getDouble();
public void setDouble(double v)

public native float getFloat();
public void setFloat(float v)

public native int getInt();
public void setInt(int v)

public native long getLong();
public void setLong(long v)

public native short getShort();
public void setShort(short v)

public native String getString();
public void setString(String v)

public native boolean isNull();
public void setNull()

public Object getObject()
public Object getObject(Class c)
public void setObject(Object value)

6. fcntl

6. fcntl

先前我们以read终端设备为例介绍了非阻塞I/O,为什么我们不直接对STDIN_FILENO做非阻塞read,而要重新open一遍/dev/tty呢?因为STDIN_FILENO在程序启动时已经被自动打开了,而我们需要在调用open时指定O_NONBLOCK标志。这里介绍另外一种办法,可以用fcntl函数改变一个已打开的文件的属性,可以重新设置读、写、追加、非阻塞等标志(这些标志称为File Status Flag),而不必重新open文件。

#include <unistd.h>
#include <fcntl.h>

int fcntl(int fd, int cmd);
int fcntl(int fd, int cmd, long arg);
int fcntl(int fd, int cmd, struct flock *lock);

这个函数和open一样,也是用可变参数实现的,可变参数的类型和个数取决于前面的cmd参数。下面的例子使用F_GETFL和F_SETFL这两种fcntl命令改变STDIN_FILENO的属性,加上O_NONBLOCK选项,实现和例 28.3 “非阻塞读终端”同样的功能。

例 28.5. 用fcntl改变File Status Flag

#include <unistd.h>
#include <fcntl.h>
#include <errno.h>
#include <string.h>
#include <stdlib.h>

#define MSG_TRY "try again\n"

int main(void)
{
char buf[10];
int n;
int flags;
flags = fcntl(STDIN_FILENO, F_GETFL);
flags |= O_NONBLOCK;
if (fcntl(STDIN_FILENO, F_SETFL, flags) == -1) {
perror("fcntl");
exit(1);
}
tryagain:
n = read(STDIN_FILENO, buf, 10);
if (n < 0) {
if (errno == EAGAIN) {
sleep(1);
write(STDOUT_FILENO, MSG_TRY, strlen(MSG_TRY));
goto tryagain;
}
perror("read stdin");
exit(1);
}
write(STDOUT_FILENO, buf, n);
return 0;
}


以下程序通过命令行的第一个参数指定一个文件描述符,同时利用shell的重定向功能在该描述符上打开文件,然后用fcntl的F_GETFL命令取出File Status Flag并打印。

#include <sys/types.h>
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>

int main(int argc, char *argv[])
{
int val;
if (argc != 2) {
fputs("usage: a.out <descriptor#>\n", stderr);
exit(1);
}
if ((val = fcntl(atoi(argv[1]), F_GETFL)) < 0) {
printf("fcntl error for fd %d\n", atoi(argv[1]));
exit(1);
}
switch(val & O_ACCMODE) {
case O_RDONLY:
printf("read only");
break;
case O_WRONLY:
printf("write only");
break;
case O_RDWR:printf("read write");
break;
default:
fputs("invalid access mode\n", stderr);
exit(1);
}
if (val & O_APPEND)printf(", append");
if (val & O_NONBLOCK)
printf(", nonblocking");
putchar('\n');
return 0;
}

运行该程序的几种情况解释如下。

$ ./a.out 0 < /dev/tty
read only

shell在执行a.out时将它的标准输入重定向到/dev/tty,并且是只读的。argv[1]是0,因此取出文件描述符0(也就是标准输入)的File Status Flag,用掩码O_ACCMODE取出它的读写位,结果是O_RDONLY。注意,Shell的重定向语法不属于程序的命令行参数,这个命行只有两个参数,argv[]是"./a.out",argv[1]是"0",重定向由Shell解释,在启动程序时已经生效,程序在运行时并不知道标准输入被重定向了。

$ ./a.out 1 > temp.foo
$ cat temp.foo
write only

Shell在执行a.out时将它的标准输出重定向到文件temp.foo,并且是只写的。程序取出文件描述符1的File Status Flag,发现是只写的,于是打印write only,但是打印不到屏幕上而是打印到temp.foo这个文件中了。

$ ./a.out 2 2>>temp.foo
write only, append

Shell在执行a.out时将它的标准错误输出重定向到文件temp.foo,并且是只写和追加方式。程序取出文件描述符2的File Status Flag,发现是只写和追加方式的。

$ ./a.out 5 5<>temp.foo
read write

Shell在执行a.out时在它的文件描述符5上打开文件temp.foo,并且是可读可写的。程序取出文件描述符5的File Status Flag,发现是可读可写的。

我们看到一种新的Shell重定向语法,如果在<、>、>>、<>前面添一个数字,该数字就表示在哪个文件描述符上打开文件,例如2>>temp.foo表示将标准错误输出重定向到文件temp.foo并且以追加方式写入文件,注意2和>>之间不能有空格,否则2就被解释成命令行参数了。文件描述符数字还可以出现在重定向符号右边,例如:

$ command > /dev/null 2>&1

首先将某个命令command的标准输出重定向到/dev/null,然后将该命令可能产生的错误信息(标准错误输出)也重定向到和标准输出(用&1标识)相同的文件,即/dev/null,如下图所示。

图 28.3. 重定向之后的文件描述符表


/dev/null设备文件只有一个作用,往它里面写任何数据都被直接丢弃。因此保证了该命令执行时屏幕上没有任何输出,既不打印正常信息也不打印错误信息,让命令安静地执行,这种写法在Shell脚本中很常见。注意,文件描述符数字写在重定向符号右边需要加&号,否则就被解释成文件名了,2>&1其中的>左右两边都不能有空格。

除了F_GETFL和F_SETFL命令之外,fcntl还有很多命令做其它操作,例如设置文件记录锁等。可以通过fcntl设置的都是当前进程如何访问设备或文件的访问控制属性,例如读、写、追加、非阻塞、加锁等,但并不设置文件或设备本身的属性,例如文件的读写权限、串口波特率等。下一节要介绍的ioctl函数用于设置某些设备本身的属性,例如串口波特率、终端窗口大小,注意区分这两个函数的作用。

4. read/write

4. read/write

read函数从打开的设备或文件中读取数据。

#include <unistd.h>

ssize_t read(int fd, void *buf, size_t count);
返回值:成功返回读取的字节数,出错返回-1并设置errno,如果在调read之前已到达文件末尾,则这次read返回0

参数count是请求读取的字节数,读上来的数据保存在缓冲区buf中,同时文件的当前读写位置向后移。注意这个读写位置和使用C标准I/O库时的读写位置有可能不同,这个读写位置是记在内核中的,而使用C标准I/O库时的读写位置是用户空间I/O缓冲区中的位置。比如用fgetc读一个字节,fgetc有可能从内核中预读1024个字节到I/O缓冲区中,再返回第一个字节,这时该文件在内核中记录的读写位置是1024,而在FILE结构体中记录的读写位置是1。注意返回值类型是ssize_t,表示有符号的size_t,这样既可以返回正的字节数、0(表示到达文件末尾)也可以返回负值-1(表示出错)。read函数返回时,返回值说明了buf中前多少个字节是刚读上来的。有些情况下,实际读到的字节数(返回值)会小于请求读的字节数count,例如:

  • 读常规文件时,在读到count个字节之前已到达文件末尾。例如,距文件末尾还有30个字节而请求读100个字节,则read返回30,下次read将返回0。

  • 从终端设备读,通常以行为单位,读到换行符就返回了。

  • 从网络读,根据不同的传输层协议和内核缓存机制,返回值可能小于请求的字节数,后面socket编程部分会详细讲解。

write函数向打开的设备或文件中写数据。

#include <unistd.h>

ssize_t write(int fd, const void *buf, size_t count);
返回值:成功返回写入的字节数,出错返回-1并设置errno

写常规文件时,write的返回值通常等于请求写的字节数count,而向终端设备或网络写则不一定。

读常规文件是不会阻塞的,不管读多少字节,read一定会在有限的时间内返回。从终端设备或网络读则不一定,如果从终端输入的数据没有换行符,调用read读终端设备就会阻塞,如果网络上没有接收到数据包,调用read从网络读就会阻塞,至于会阻塞多长时间也是不确定的,如果一直没有数据到达就一直阻塞在那里。同样,写常规文件是不会阻塞的,而向终端设备或网络写则不一定。

现在明确一下阻塞(Block)这个概念。当进程调用一个阻塞的系统函数时,该进程被置于睡眠(Sleep)状态,这时内核调度其它进程运行,直到该进程等待的事件发生了(比如网络上接收到数据包,或者调用sleep指定的睡眠时间到了)它才有可能继续运行。与睡眠状态相对的是运行(Running)状态,在linux内核中,处于运行状态的进程分为两种情况:

  • 正在被调度执行。CPU处于该进程的上下文环境中,程序计数器(eip)里保存着该进程的指令地址,通用寄存器里保存着该进程运算过程的中间结果,正在执行该进程的指令,正在读写该进程的地址空间。

  • 就绪状态。该进程不需要等待什么事件发生,随时都可以执行,但CPU暂时还在执行另一个进程,所以该进程在一个就绪队列中等待被内核调度。系统中可能同时有多个就绪的进程,那么该调度谁执行呢?内核的调度算法是基于优先级和时间片的,而且会根据每个进程的运行情况动态调整它的优先级和时间片,让每个进程都能比较公平地得到机会执行,同时要兼顾用户体验,不能让和用户交互的进程响应太慢。

下面这个小程序从终端读数据再写回终端。

例 28.2. 阻塞读终端

#include <unistd.h>
#include <stdlib.h>

int main(void)
{
char buf[10];
int n;
n = read(STDIN_FILENO, buf, 10);
if (n < 0) {
perror("read STDIN_FILENO");
exit(1);
}
write(STDOUT_FILENO, buf, n);
return 0;
}


执行结果如下:

$ ./a.out
hello(回车)
hello
$ ./a.out
hello world(回车)
hello worl$ d
bash: d: command not found

第一次执行a.out的结果很正常,而第二次执行的过程有点特殊,现在分析一下:

  • shell进程创建a.out进程,a.out进程开始执行,而shell进程睡眠等待a.out进程退出。

  • a.out调用read时睡眠等待,直到终端设备输入了换行符才从read返回,read只读走10个字符,剩下的字符仍然保存在内核的终端设备输入缓冲区中。

  • a.out进程打印并退出,这时Shell进程恢复运行,Shell继续从终端读取用户输入的命令,于是读走了终端设备输入缓冲区中剩下的字符d和换行符,把它当成一条命令解释执行,结果发现执行不了,没有d这个命令。

  • 如果在open一个设备时指定了O_NONBLOCK标志,read/write就不会阻塞。以read为例,如果设备暂时没有数据可读就返回-1,同时置errno为EWOULDBLOCK(或者EAGAIN,这两个宏定义的值相同),表示本来应该阻塞在这里(would block,虚拟语气),事实上并没有阻塞而是直接返回错误,调用者应该试着再读一次(again)。这种行为方式称为轮询(Poll),调用者只是查询一下,而不是阻塞在这里死等,这样可以同时监视多个设备:

    while(1) {
    非阻塞read(设备1);
    if(设备1有数据到达)
    处理数据;
    非阻塞read(设备2);
    if(设备2有数据到达)
    处理数据;
    ...
    }

    如果read(设备1)是阻塞的,那么只要设备1没有数据到达就会一直阻塞在设备1的read调用上,即使设备2有数据到达也不能处理,使用非阻塞I/O就可以避免设备2得不到及时处理。

    非阻塞I/O有一个缺点,如果所有设备都一直没有数据到达,调用者需要反复查询做无用功,如果阻塞在那里,操作系统可以调度别的进程执行,就不会做无用功了。在使用非阻塞I/O时,通常不会在一个while循环中一直不停地查询(这称为Tight Loop),而是每延迟等待一会儿来查询一下,以免做太多无用功,在延迟等待的时候可以调度其它进程执行。

    while(1) {
    非阻塞read(设备1);
    if(设备1有数据到达)
    处理数据;
    非阻塞read(设备2);
    if(设备2有数据到达)
    处理数据;
    ...
    sleep(n);
    }

    这样做的问题是,设备1有数据到达时可能不能及时处理,最长需延迟n秒才能处理,而且反复查询还是做了很多无用功。以后要学习的select(2)函数可以阻塞地同时监视多个设备,还可以设定阻塞等待的超时时间,从而圆满地解决了这个问题。

    以下是一个非阻塞I/O的例子。目前我们学过的可能引起阻塞的设备只有终端,所以我们用终端来做这个实验。程序开始执行时在0、1、2文件描述符上自动打开的文件就是终端,但是没有O_NONBLOCK标志。所以就像例 28.2 “阻塞读终端”一样,读标准输入是阻塞的。我们可以重新打开一遍设备文件/dev/tty(表示当前终端),在打开时指定O_NONBLOCK标志。

    例 28.3. 非阻塞读终端

    #include <unistd.h>
    #include <fcntl.h>
    #include <errno.h>
    #include <string.h>
    #include <stdlib.h>

    #define MSG_TRY "try again\n"

    int main(void)
    {
    char buf[10];
    int fd, n;
    fd = open("/dev/tty", O_RDONLY|O_NONBLOCK);
    if(fd<0) {
    perror("open /dev/tty");
    exit(1);
    }
    tryagain:
    n = read(fd, buf, 10);
    if (n < 0) {
    if (errno == EAGAIN) {
    sleep(1);
    write(STDOUT_FILENO, MSG_TRY, strlen(MSG_TRY));
    goto tryagain;
    }
    perror("read /dev/tty");
    exit(1);
    }
    write(STDOUT_FILENO, buf, n);
    close(fd);
    return 0;
    }


    以下是用非阻塞I/O实现等待超时的例子。既保证了超时退出的逻辑又保证了有数据到达时处理延迟较小。

    例 28.4. 非阻塞读终端和等待超时

    #include <unistd.h>
    #include <fcntl.h>
    #include <errno.h>
    #include <string.h>
    #include <stdlib.h>

    #define MSG_TRY "try again\n"
    #define MSG_TIMEOUT "timeout\n"

    int main(void)
    {
    char buf[10];
    int fd, n, i;
    fd = open("/dev/tty", O_RDONLY|O_NONBLOCK);
    if(fd<0) {
    perror("open /dev/tty");
    exit(1);
    }
    for(i=0; i<5; i++) {
    n = read(fd, buf, 10);
    if(n>=0)
    break;
    if(errno!=EAGAIN) {
    perror("read /dev/tty");
    exit(1);
    }
    sleep(1);
    write(STDOUT_FILENO, MSG_TRY, strlen(MSG_TRY));
    }
    if(i==5)
    write(STDOUT_FILENO, MSG_TIMEOUT, strlen(MSG_TIMEOUT));
    else
    write(STDOUT_FILENO, buf, n);
    close(fd);
    return 0;
    }


    5. lseek

    5. lseek

    每个打开的文件都记录着当前读写位置,打开文件时读写位置是0,表示文件开头,通常读写多少个字节就会将读写位置往后移多少个字节。但是有一个例外,如果以O_APPEND方式打开,每次写操作都会在文件末尾追加数据,然后将读写位置移到新的文件末尾。lseek和标准I/O库的fseek函数类似,可以移动当前读写位置(或者叫偏移量)。

    #include <sys/types.h>
    #include <unistd.h>
    

    off_t lseek(int fd, off_t offset, int whence);

    参数offset和whence的含义和fseek函数完全相同。只不过第一个参数换成了文件描述符。和fseek一样,偏移量允许超过文件末尾,这种情况下对该文件的下一次写操作将延长文件,中间空洞的部分读出来都是0。

    若lseek成功执行,则返回新的偏移量,因此可用以下方法确定一个打开文件的当前偏移量:

    off_t currpos;
    currpos = lseek(fd, 0, SEEK_CUR);

    这种方法也可用来确定文件或设备是否可以设置偏移量,常规文件都可以设置偏移量,而设备一般是不可以设置偏移量的。如果设备不支持lseek,则lseek返回-1,并将errno设置为ESPIPE。注意fseek和lseek在返回值上有细微的差别,fseek成功时返回0失败时返回-1,要返回当前偏移量需调用ftell,而lseek成功时返回当前偏移量失败时返回-1。

    2. C标准I/O库函数与Unbuffered I/O函数

    2. C标准I/O库函数与Unbuffered I/O函数

    现在看看C标准I/O库函数是如何用系统调用实现的。

    fopen(3)

    调用open(2)打开指定的文件,返回一个文件描述符(就是一个int类型的编号),分配一个FILE结构体,其中包含该文件的描述符、I/O缓冲区和当前读写位置等信息,返回这个FILE结构体的地址。

    fgetc(3)

    通过传入的FILE *参数找到该文件的描述符、I/O缓冲区和当前读写位置,判断能否从I/O缓冲区中读到下一个字符,如果能读到就直接返回该字符,否则调用read(2),把文件描述符传进去,让内核读取该文件的数据到I/O缓冲区,然后返回下一个字符。注意,对于C标准I/O库来说,打开的文件由FILE *指针标识,而对于内核来说,打开的文件由文件描述符标识,文件描述符从open系统调用获得,在使用read、write、close系统调用时都需要传文件描述符。

    fputc(3)

    判断该文件的I/O缓冲区是否有空间再存放一个字符,如果有空间则直接保存在I/O缓冲区中并返回,如果I/O缓冲区已满就调用write(2),让内核把I/O缓冲区的内容写回文件。

    fclose(3)

    如果I/O缓冲区中还有数据没写回文件,就调用write(2)写回文件,然后调用close(2)关闭文件,释放FILE结构体和I/O缓冲区。

    以写文件为例,C标准I/O库函数(printf(3)、putchar(3)、fputs(3))与系统调用write(2)的关系如下图所示。

    图 28.1. 库函数与系统调用的层次关系


    open、read、write、close等系统函数称为无缓冲I/O(Unbuffered I/O)函数,因为它们位于C标准库的I/O缓冲区的底层[36]。用户程序在读写文件时既可以调用C标准I/O库函数,也可以直接调用底层的Unbuffered I/O函数,那么用哪一组函数好呢?

    • 用Unbuffered I/O函数每次读写都要进内核,调一个系统调用比调一个用户空间的函数要慢很多,所以在用户空间开辟I/O缓冲区还是必要的,用C标准I/O库函数就比较方便,省去了自己管理I/O缓冲区的麻烦。

    • 用C标准I/O库函数要时刻注意I/O缓冲区和实际文件有可能不一致,在必要时需调用fflush(3)。

    • 我们知道UNIX的传统是Everything is a file,I/O函数不仅用于读写常规文件,也用于读写设备,比如终端或网络设备。在读写设备时通常是不希望有缓冲的,例如向代表网络设备的文件写数据就是希望数据通过网络设备发送出去,而不希望只写到缓冲区里就算完事儿了,当网络设备接收到数据时应用程序也希望第一时间被通知到,所以网络编程通常直接调用Unbuffered I/O函数。

    C标准库函数是C标准的一部分,而Unbuffered I/O函数是UNIX标准的一部分,在所有支持c语言的平台上应该都可以用C标准库函数(除了有些平台的C编译器没有完全符合C标准之外),而只有在UNIX平台上才能使用Unbuffered I/O函数,所以C标准I/O库函数在头文件stdio.h中声明,而read、write等函数在头文件unistd.h中声明。在支持c语言的非UNIX操作系统上,标准I/O库的底层可能由另外一组系统函数支持,例如Windows系统的底层是win32 API,其中读写文件的系统函数是ReadFile、WriteFile。

    关于UNIX标准

    POSIX(Portable Operating System Interface)是由IEEE制定的标准,致力于统一各种UNIX系统的接口,促进各种UNIX系统向互相兼容的发向发展。IEEE 1003.1(也称为POSIX.1)定义了UNIX系统的函数接口,既包括C标准库函数,也包括系统调用和其它UNIX库函数。POSIX.1只定义接口而不定义实现,所以并不区分一个函数是库函数还是系统调用,至于哪些函数在用户空间实现,哪些函数在内核中实现,由操作系统的开发者决定,各种UNIX系统都不太一样。IEEE 1003.2定义了shell的语法和各种基本命令的选项等。本书的第三部分不仅讲解基本的系统函数接口,也顺带讲解shell、基本命令、帐号和权限以及系统管理的基础知识,这些内容合在一起定义了UNIX系统的基本特性。

    在UNIX的发展历史上主要分成BSD和SYSV两个派系,各自实现了很多不同的接口,比如BSD的网络编程接口是socket,而SYSV的网络编程接口是基于STREAMS的TLI。POSIX在统一接口的过程中,有些接口借鉴BSD的,有些接口借鉴SYSV的,还有些接口既不是来自BSD也不是来自SYSV,而是凭空发明出来的(例如本书要讲的pthread库就属于这种情况),通过Man Page的COMFORMING TO部分可以看出来一个函数接口属于哪种情况。linux的源代码是完全从头编写的,并不继承BSD或SYSV的源代码,没有历史的包袱,所以能比较好地遵照POSIX标准实现,既有BSD的特性也有SYSV的特性,此外还有一些linux特有的特性,比如epoll(7),依赖于这些接口的应用程序是不可移植的,但在Linux系统上运行效率很高。

    POSIX定义的接口有些规定是必须实现的,而另外一些是可以选择实现的。有些非UNIX系统也实现了POSIX中必须实现的部分,那么也可以声称自己是POSIX兼容的,然而要想声称自己是UNIX,还必须要实现一部分在POSIX中规定为可选实现的接口,这由另外一个标准SUS(Single UNIX Specification)规定。SUS是POSIX的超集,一部分在POSIX中规定为可选实现的接口在SUS中规定为必须实现,完整实现了这些接口的系统称为XSI(X/Open System Interface)兼容的。SUS标准由The Open Group维护,该组织拥有UNIX的注册商标(http://www.unix.org/),XSI兼容的系统可以从该组织获得授权使用UNIX这个商标。

    现在该说说文件描述符了。每个进程在Linux内核中都有一个task_struct结构体来维护进程相关的信息,称为进程描述符(Process Descriptor),而在操作系统理论中称为进程控制块(PCB,Process Control Block)。task_struct中有一个指针指向files_struct结构体,称为文件描述符表,其中每个表项包含一个指向已打开的文件的指针,如下图所示。

    图 28.2. 文件描述符表


    至于已打开的文件在内核中用什么结构体表示,我们将在下一章详细介绍,目前我们在画图时用一个圈表示。用户程序不能直接访问内核中的文件描述符表,而只能使用文件描述符表的索引(即0、1、2、3这些数字),这些索引就称为文件描述符(File Descriptor),用int型变量保存。当调用open打开一个文件或创建一个新文件时,内核分配一个文件描述符并返回给用户程序,该文件描述符表项中的指针指向新打开的文件。当读写文件时,用户程序把文件描述符传给read或write,内核根据文件描述符找到相应的表项,再通过表项中的指针找到相应的文件。

    我们知道,程序启动时会自动打开三个文件:标准输入、标准输出和标准错误输出。在C标准库中分别用FILE *指针stdin、stdout和stderr表示。这三个文件的描述符分别是0、1、2,保存在相应的FILE结构体中。头文件unistd.h中有如下的宏定义来表示这三个文件描述符:

    #define STDIN_FILENO 0
    #define STDOUT_FILENO 1
    #define STDERR_FILENO 2

    [36] 事实上Unbuffered I/O这个名词是有些误导的,虽然write系统调用位于C标准库I/O缓冲区的底层,但在write的底层也可以分配一个内核I/O缓冲区,所以write也不一定是直接写到文件的,也可能写到内核I/O缓冲区中,至于究竟写到了文件中还是内核缓冲区中对于进程来说是没有差别的,如果进程A和进程B打开同一文件,进程A写到内核I/O缓冲区中的数据从进程B也能读到,而C标准库的I/O缓冲区则不具有这一特性(想一想为什么)。