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

时间:2017-01-22 15:23:44

标签: c fopen

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

我正在尝试使用系统调用fopen()fillbuf()来实现openread功能。

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

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

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

#include<fcntl.h>
#include<unistd.h>
#include<stdlib.h>
#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->cnt<0){
        if(fp->cnt == -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; fp<_iob+OPEN_MAX; fp++)
        if((fp->flag & (_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;
}

2 个答案:

答案 0 :(得分:2)

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

我看到了问题。

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.h>使用malloc。

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

答案 1 :(得分:2)

对问题中代码的不同分析

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

如另一个(稍后)question and answer所述,当前Mark Yisriaccepted answer给出的诊断不正确 - 问题不是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中逐步通过数组时,不可能存在空指针。循环也可以写成:

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

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

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

这些是非常常见的问题,如果编写主程序,可能会导致程序崩溃。

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

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(标准错误)是非常繁琐的,如果不是很痛苦的话。这也意味着我采用了一些快捷方式,比如假设程序被调用mystdio而不是在错误消息中实际使用argv[0]。但是,如果在没有任何文件名的情况下调用它(或者如果给出了多个文件名),或者如果无法打开命名文件进行读取,则会产生或多或少相应的错误消息 - 并且不会崩溃。 / p>

领先的下划线

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

  • 所有以下划线开头且以大写字母或其他下划线开头的标识符始终保留供任何使用。
  • 所有以下划线开头的标识符始终保留用作普通和标记名称空间中具有文件范围的标识符。

另见What does double underscore (__const) mean in C?

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

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