K&R fopen 和 fillbuf 中 C 中的分段错误
Segmentation fault in C in K&R fopen and fillbuf
我是C的新手,在学习K&R的最后一章时遇到了问题。
我正在尝试使用系统调用 open
和 read
来实现 fopen()
和 fillbuf()
功能。
我原封不动地照着书上的源码复制过来,编译后却反复出现分段错误。
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;
}
编辑:请参阅 。它更准确,并提供更好的诊断。我的答案有效,但还有更好的方法。
我看到问题了。
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
以防止内存泄漏。
题中代码的不同分析
问题中显示的代码包含来自 K&R "The C Programming Language, 2nd Edition"(1988 年;我的副本标记为 'Based on Draft Proposed ANSI C')第 176-178 页的部分代码,但不是全部示例 main
根本不是来自本书的程序。类型的名称也从 FILE
更改为 myFILE
,并且 fopen()
重命名为 myfopen()
。我注意到问题代码中的表达式比 K&R 中的原始代码少了很多空间。编译器不介意;人类读者通常更喜欢运算符周围的空格。
如另一个(稍后)所述,question and answer, the diagnosis given by Mark Yisri in the currently accepted 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()
,它是 not — 重复 not —由 K&R 编写) 被正确调用,它工作而不会崩溃。然而,main()
程序中的代码并没有保护自己免受:
- 在没有 non-null
argv[1]
的情况下被调用。
- 正在
argv[1]
中使用 non-existent 或 non-readable 文件名调用。
这些都是很常见的问题,主程序写好了,任何一个都可能导致程序崩溃。
虽然 16 个月后很难确定,但在我看来,问题很可能出在程序的调用方式上,而不是其他任何地方。如果主程序 more-or-less 编写得当,你最终会得到类似这样的代码(你还需要将 #include <string.h>
添加到包含的 headers 列表中):
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]
。但是,如果在没有任何文件名的情况下调用它(或者如果给出了多个文件名),或者如果无法打开指定的文件进行读取,那么它会或多或少地产生一条适当的错误消息——并且不会崩溃。
前导下划线
请注意,C 标准保留以下划线开头的标识符。
通常,您不应创建以下划线开头的函数、变量或宏名称。 C11 §7.1.3 Reserved identifiers 说(部分):
- 所有以下划线和大写字母或其他下划线开头的标识符始终保留供任何使用。
- 所有以下划线开头的标识符始终保留用作普通和标记名称空间中具有文件范围的标识符。
另见 What does double underscore (__const
) mean in C?
公平地说,在编写第 1 版(1978 年)时,K&R 本质上是在描述标准 I/O 库的标准实现,在第 2 版中已充分现代化以使用函数原型表示法。原始代码位于第 1 版的第 165-168 页。
即使在今天,如果您要实现 标准库,您也会使用下划线开头的名称,因为它们是为使用 'by the implementation' 保留的。如果您没有实现标准库,则不要使用以下划线开头的名称,因为它使用为实现保留的命名空间。大多数人,大多数时候,并没有编写标准库——大多数人不应该使用前导下划线。
我是C的新手,在学习K&R的最后一章时遇到了问题。
我正在尝试使用系统调用 open
和 read
来实现 fopen()
和 fillbuf()
功能。
我原封不动地照着书上的源码复制过来,编译后却反复出现分段错误。
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;
}
编辑:请参阅
我看到问题了。
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
以防止内存泄漏。
题中代码的不同分析
问题中显示的代码包含来自 K&R "The C Programming Language, 2nd Edition"(1988 年;我的副本标记为 'Based on Draft Proposed ANSI C')第 176-178 页的部分代码,但不是全部示例 main
根本不是来自本书的程序。类型的名称也从 FILE
更改为 myFILE
,并且 fopen()
重命名为 myfopen()
。我注意到问题代码中的表达式比 K&R 中的原始代码少了很多空间。编译器不介意;人类读者通常更喜欢运算符周围的空格。
如另一个(稍后)所述,question and answer, the diagnosis given by Mark Yisri in the currently accepted 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()
,它是 not — 重复 not —由 K&R 编写) 被正确调用,它工作而不会崩溃。然而,main()
程序中的代码并没有保护自己免受:
- 在没有 non-null
argv[1]
的情况下被调用。 - 正在
argv[1]
中使用 non-existent 或 non-readable 文件名调用。
这些都是很常见的问题,主程序写好了,任何一个都可能导致程序崩溃。
虽然 16 个月后很难确定,但在我看来,问题很可能出在程序的调用方式上,而不是其他任何地方。如果主程序 more-or-less 编写得当,你最终会得到类似这样的代码(你还需要将 #include <string.h>
添加到包含的 headers 列表中):
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]
。但是,如果在没有任何文件名的情况下调用它(或者如果给出了多个文件名),或者如果无法打开指定的文件进行读取,那么它会或多或少地产生一条适当的错误消息——并且不会崩溃。
前导下划线
请注意,C 标准保留以下划线开头的标识符。 通常,您不应创建以下划线开头的函数、变量或宏名称。 C11 §7.1.3 Reserved identifiers 说(部分):
- 所有以下划线和大写字母或其他下划线开头的标识符始终保留供任何使用。
- 所有以下划线开头的标识符始终保留用作普通和标记名称空间中具有文件范围的标识符。
另见 What does double underscore (__const
) mean in C?
公平地说,在编写第 1 版(1978 年)时,K&R 本质上是在描述标准 I/O 库的标准实现,在第 2 版中已充分现代化以使用函数原型表示法。原始代码位于第 1 版的第 165-168 页。
即使在今天,如果您要实现 标准库,您也会使用下划线开头的名称,因为它们是为使用 'by the implementation' 保留的。如果您没有实现标准库,则不要使用以下划线开头的名称,因为它使用为实现保留的命名空间。大多数人,大多数时候,并没有编写标准库——大多数人不应该使用前导下划线。