文档详情

linux函数笔记.doc

发布:2017-04-03约7.72千字共9页下载文档
文本预览下载声明
UNIX环境下的C 对二进制流文件的读写有两套班子:1) fopen,fread,fwrite ; 2) open, read, write 这里简单的介绍一下他们的区别。 1. fopen 系列是标准的C库函数;open系列是 POSIX 定义的,是UNIX系统里的system call。 也就是说,fopen系列更具有可移植性;而open系列只能用在 POSIX 的操作系统上。 2. 使用fopen 系列函数时要定义一个指代文件的对象,被称为“文件句柄”(file handler),是一个结构体;而open系列使用的是一个被称为“文件描述符” (file descriptor)的int型整数。 3. fopen 系列是级别较高的I/O,读写时使用缓冲;而open系列相对低层,更接近操作系统,读写时没有缓冲。由于能更多地与操作系统打交道,open系列可以访问更改一些fopen系列无法访问的信息,如查看文件的读写权限。这些额外的功能通常因系统而异。 4. 使用fopen系列函数需要#include sdtio.h;使用open系列函数需要#include fcntl.h ,链接时要之用libc(-lc) 小结: 总的来说,为了使程序获得更好的 1、 open 是系统调用 返回的是文件句柄,文件的句柄是文件在文件描述副表里的索引,fopen是C的库函数,返回的是一个指向文件结构的指针。 2、 fopen的实现要调用open, 关键看你想返回什么了, FILE指针还是描述符? 3、 32位环境下,编译加“-D_FILE_OFFSET_BITS=64” 要在open里加O_LARGEFILE标记 [code] static int ext2_open_file (struct inode * inode, struct file * filp) { ? ? ? ? if (!(filp-f_flags O_LARGEFILE) ? ? ? ?? ???inode-i_size 0x7FFFFFFFLL) ? ? ? ? ? ? ? ? return -EFBIG; ? ? ? ? return 0; } [/code] 0x7FFFFFFF就是2G-1。 看一下这个逻辑, 就知道open时必须制定O_LARGEFILE. 4、 fopen一个文件,fclose两次,会是什么样的情况? 本人测试了一下: 在aix,hp,sco,unixware上fclose第一次成功,fclose第二次返回错误 在linux上.fclose第一次成功,第二次报segmentation fault,程序吐核 5、 计算机语言遵循的规范称为标准。C语言有C标准,C++语言有C++标准。标准中详细规定了你能够做什么和不能做什么。标准中规定不能做的就是我说的标准的禁止事项。 其实不只是标准,在介绍学习或使用语言的书中也会出现大量的应该做和不应该做的说明,只是一般不可能象标准那样全面。所以,在“The C Programming Language”中没有提到这个未定义行为也没有什么奇怪的。 程序员基本职责?…… 可以认为是为了实现程序预定的目的,对程序员的基本要求。在使用语言上的一个基本要求就是要符合标准规定。 还有一个问题 在非linux系统下,我使用fopen打开的文件 使用close关闭(注意,不是fclose),缓冲也相应关闭; 而在linux系统下,如果使用close关闭,结果缓冲还残留在内存中. 这个是不是说明linux 不支持标准? 如果用 close 来关闭一个缓冲文件,其行为是未定义的。因为 close 并不能保证刷新缓存,所以 fclose != close,不过可以这样认为:fclose = fflush + close。 既然 close 用 fopen 打开的文件是一种未定义行为,就是说标准没有规定这样会导致什么行为,所以结果导致缓冲刷新也罢不刷新也罢,这样的行为都是合法的,编译器可以自由实现。 由于未定义行为是标准规定的禁止在程序中出现的行为,所以一般没有必要再去讨论未定义行为到底有什么、或者有哪些具体的表现。 那我觉得linux下编译的过程中就应该发出警告,fclose两次是未定义的,有潜在危险 想法是不错的。只不过未定义行为不是语法错误,在编译阶段一般是发现不了的,或者实现起来相当困难,只好推移到运行阶段、借助于程序的行为异常来发现这些错误。比如,fclose两次、除数为0、悬挂指针等带来的行为。当然,也可能因在运行时程序表现正常而发现不了这些错误。这就要求我们在写程序的时候就要尽量处理好,不要出现未定义的行为。对于编译器而言呢,我们希望它会以一种尽量“醒目”的方式提示我
显示全部
相似文档