K&R fopen和fillbuf中C的分段错误

我对C.很新。我在研究K&R的最后一章时遇到了一个问题。

我正在尝试通过使用系统调用, openread来实现fopen()fillbuf()函数。

我完全复制了书中的源代码,但在编译后反复出现分段错误。

  fp->fd = fd; fp->cnt = 0; fp->base = NULL; fp->flag = (*mode=='r')? _READ : _WRITE; 

为什么会出现错误? 这是我的完整代码。

 #include #include #include #define PERM 0644 #define EOF (-1) #define BUFSIZE 1024 #define OPEN_MAX 20 typedef struct _iobuf{ int cnt; char *ptr; char *base; int flag; int fd; } myFILE; enum _flags { _READ = 01, _WRITE = 02, _UNBUF = 04, _EOF = 010, _ERR = 020 }; myFILE _iob[OPEN_MAX]={ {0, (char *) 0, (char *) 0, _READ, 0 }, {0, (char *) 0, (char *) 0, _WRITE, 1 }, {0, (char *) 0, (char *) 0, _WRITE | _UNBUF, 2 } }; #define stdin (&_iob[0]) #define stdout (&_iob[1]) #define stderr (&_iob[2]) #define getc(p) ( --(p)->cnt>=0 ? (unsigned char) *(p)->ptr++ : _fillbuf(p) ) int _fillbuf(myFILE *fp) { int bufsize; if((fp->flag & (_READ|_EOF|_ERR))!=_READ) return EOF; bufsize=(fp->flag & _UNBUF)? 1 : BUFSIZE; if(fp->base==NULL) if((fp->base=(char *)malloc(bufsize))==NULL) return EOF; fp->ptr=fp->base; fp->cnt=read(fp->fd, fp->ptr, bufsize); if(--fp->cntcnt == -1) fp->flag |= _EOF; else fp->flag |= _ERR; return EOF; } return (unsigned char) *fp->ptr++; } myFILE *myfopen(char *name, char *mode) { int fd; myFILE *fp; if(*mode!='r' && *mode!='w' && *mode!='a') return NULL; for(fp=_iob; fpflag & (_READ | _WRITE))==0) break; if(fp>=_iob+OPEN_MAX) return NULL; if(*mode=='w') fd=creat(name, PERM); else if(*mode=='a'){ if((fd=open(name, O_WRONLY, 0))==-1) fd=creat(name, PERM); lseek(fd, 0L, 2); } else fd=open(name, O_RDONLY, 0); if(fd==-1) return NULL; fp->fd = fd; fp->cnt = 0; fp->base = NULL; fp->flag = (*mode=='r')? _READ : _WRITE; return fp; } int main(int argc, char *argv[]) { myFILE *fp; int c; if((fp=myfopen(argv[1], "r"))!=NULL) write(1, "opened\n", sizeof("opened\n")); while((c=getc(fp))!=EOF) write(1, &c, sizeof(c)); return 0; } 

编辑:请参阅Jonathan Leffler的回答 。 它更准确,并提供更好的诊断。 我的回答有效,但有更好的方法可以做。

我看到了问题。

 myFILE *fp; if(*mode!='r' && *mode!='w' && *mode!='a') return NULL; for(fp=_iob; fp<_iob+OPEN_MAX; fp++) if((fp->flag & (_READ | _WRITE))==0) // marked line break; 

当您到达marked line ,您尝试取消引用fp指针。 由于它(可能但不一定)初始化为零(但我应该说为NULL ),因此您将取消引用空指针。 繁荣。 段错误。

这是你需要改变的。

 myFILE *fp = (myFILE *)malloc(sizeof(myFILE)); 

一定要#include 来使用malloc。

此外,您的close函数应该稍后free()您的myFILE以防止内存泄漏。

对问题中代码的不同分析

问题中显示的代码包括K&R“C编程语言,第2版”(1988;我的副本标记为“基于提议的ANSI C草案”),第176-178页的代码的部分,但不是全部,加上一本完全不在书中的主程序样本。 类型的名称也从FILE更改为myFILEfopen()重命名为myfopen() 。 我注意到问题中代码中的表达式比K&R中的原始代码少得多。 编译器不介意; 人类读者通常喜欢运营商周围的空间

正如另一个(后面) 问题和答案中所述, Mark Yisri在当前接受的答案中给出的诊断是不正确的 – 问题不是for循环中的空指针。 规定的补救措施有效(只要程序被正确调用),但内存分配不是必需的。 幸运的是,对于所有相关人员来说, fclose()函数未包含在实现中,因此一旦打开文件就无法关闭它。

特别是循环:

 for (fp = _iob; fp < _iob + OPEN_MAX; fp++) if ((fp->flag & (_READ | _WRITE)) == 0) break; 

完全没问题,因为数组_iob被定义为:

 FILE _iob[OPEN_MAX] = { …initializers for stdin, stdout, stderr… }; 

这是一个结构数组,而不是结构指针。 前三个元素被明确初始化; 其余元素被隐式初始化为全零。 因此,当fp逐步通过数组时, fp不存在空指针。 循环也可以写成:

 for (fp = &_iob[0]; fp < &_iob[OPEN_MAX]; fp++) if ((fp->flag & (_READ | _WRITE)) == 0) break; 

根据经验,如果问题中显示的代码(包括不是 – 重复的 – 不是 – 由K&R编写)被正确调用,它可以正常工作而不会崩溃。 但是, main()程序中的代码不能保护自己:

  • 在没有非null argv[1]情况下调用。
  • argv[1]使用不存在或不可读的文件名argv[1]

这些是非常常见的问题,并且在编写主程序时,可能会导致程序崩溃。

尽管16个月之后很难确定,但似乎问题在于程序被调用而不是其他任何东西。 如果主程序的编写顺序或多或少,那么最终会得到与此类似的代码(您还需要将#include 添加到包含的头文件列表中):

 int main(int argc, char *argv[]) { myFILE *fp; int c; if (argc != 2) { static const char usage[] = "Usage: mystdio filename\n"; write(2, usage, sizeof(usage) - 1); return 1; } if ((fp = myfopen(argv[1], "r")) == NULL) { static const char filenotopened[] = "mystdio: failed to open file "; write(2, filenotopened, sizeof(filenotopened) - 1); write(2, argv[1], strlen(argv[1])); write(2, "\n", 1); return 1; } write(1, "opened\n", sizeof("opened\n")); while ((c = getc(fp)) != EOF) write(1, &c, sizeof(c)); return 0; } 

这不能使用fprintf()等因为标准I / O库的代理实现不完整。 使用write()将错误直接写入文件描述符2(标准错误write()是非常繁琐的,如果不是很痛苦的话。 这也意味着我采取了一些快捷方式,比如假设程序名为mystdio而不是在错误消息中实际使用argv[0] 。 但是,如果在没有任何文件名的情况下调用它(或者如果给出了多个文件名),或者如果无法打开命名文件进行读取,则会产生或多或少的相应错误消息 – 并且不会崩溃。

领先的下划线

请注意,C标准保留以下划线开头的标识符。 通常,您不应创建以下划线开头的函数,变量或宏名称。 C11§7.1.3保留标识符 (部分):

  • 所有以下划线开头的标识符以及大写字母或另一个下划线始终保留用于任何用途。
  • 所有以下划线开头的标识符始终保留用作普通和标记名称空间中具有文件范围的标识符。

另请参阅双下划线( __const )在C中的含义是什么?

公平地说,K&R基本上描述了编写第1版(1978年)时标准I / O库的标准实现,现代化足以在第2版中使用函数原型符号。 原始代码位于第1版的第165-168页。

即使在今天,如果您正在实现标准库,您也会使用以下划线开头的名称,因为它们保留供“实现”使用。 如果您没有实现标准库,则不要使用以下划线开头的名称,因为它使用为实现保留的名称空间。 大多数人,大多数时候都没有编写标准库 – 大多数人不应该使用前导下划线。