调用fopen时的内存分配不明确 [英] Memory allocation when fopen is called is not clear

查看:166
本文介绍了调用fopen时的内存分配不明确的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

1. File *fp;
2. fp = fopen ("/etc/myfile.txt", "w");
3. fclose(fp);

现在

我读了:

在语句1中,在堆栈上为类型为"FILE"的指针创建了一个4字节的内存.

In statement 1, a 4 byte memory for the pointer is created of type 'FILE' on stack.

在语句2中,在堆上分配了一个memory ='sizeof(FILE)',并将其地址分配给了指针'fp'.

In statement 2, a memory = 'sizeof(FILE)' is allocated on heap, and address of which is assigned to the pointer 'fp'.

有人可以对语句2进行更多解释吗?我们是否为所有文件分配相同的堆大小?操作系统如何知道应分配的文件大小?
在较低的级别上,st 2中到底发生了什么.

Can somebody explain more on statement 2. Are we allocating same heap size for all the files? How does the O.S know the size of FILE it should allocate?
At the low level what exactly happens in st 2.

推荐答案

步骤1在堆栈上分配一个指针(如果在函数中),或者将引用全局空间中的现有保留位置(数据段或类似位置)如果在函数外部-在后一种情况下,它是在编译时保留的,即由编译器确定,而不是在运行时分配.在32位环境中,指针将为4字节;在64位环境中,指针将为8字节.

Step 1 allocates a pointer on the stack (if it's in a function), or will refer to an existing reserved location in global space (data segment or similar) if outside a function - in the latter case this is reserved at compile time, i.e. determined by the compiler, rather than allocated at run time. The pointer will be 4 bytes in a 32 bit environment and 8 bytes in a 64 bit environment.

第2步调用fopen().该行本身不分配内存,但是fopen()的实现很可能会做到.您不知道它分配了什么,因为它取决于实现.但是,您可以确定它将分配大小为sizeof FILE的结构.您还知道fopen()用于缓冲的I/O,因此它可能会分配一个缓冲区,或者可能在您第一次使用该文件时完成.您没有办法知道,因为它依赖于实现.但是,POSIX <stdio.h>指定缓冲区的长度为BUFSIZ,因此可以肯定地说,实际上分配缓冲区时,缓冲区大小至少应为该大小,因此当缓冲区分配时,它将位于内存中结构的大小至少为BUFSIZ.不需要在堆上(它可以直接用MAP_ANON调用mmap并保留指向它的指针);同样,它取决于实现.但是,可以肯定的是,它在堆上.

Step 2 calls fopen(). The line itself doesn't allocate memory, but the implementation of fopen() may well do. You don't know what this allocates, as it's implementation dependent. However, you can be pretty sure it's going to allocate a structure of size sizeof FILE. You also know that fopen() is for buffered I/O, so it might allocate a buffer, or this might be done the first time you use the file. You have no way of knowing, as it's implementation dependent. However, POSIX <stdio.h> specifies the buffer is of length BUFSIZ so it's a fair bet that when it is in fact allocated, it will be at least that size, so when the buffer does get allocated, it will be within a memory structure at least of size BUFSIZ. There is no requirement that this is on the heap (it might directly call mmap with MAP_ANON and retain a pointer to it); again, it's implementation dependent. However, a fair bet is that it's on the heap.

第3步调用fclose().这将释放在步骤2进行的分配,但不会释放在步骤1进行的分配(如果有).

Step 3 calls fclose(). This will free the allocation made at step 2, but not the allocation (if any) made at step 1.

回答您的问题操作系统如何知道FILE的大小" :FILE是C结构(对于struct实际上是typedef).因此,它的大小是C编译器已知的,并将被传递给使用的任何分配器,例如堆分配器.如果使用了堆分配器,则它甚至对OS都不可见,因为它将在您的C库中处理.

Re your question 'how does the OS know the size of FILE': FILE is a C structure (actually a typedef for a struct). As such its size is known to the C compiler, and will be passed to whatever allocator is used, e.g. the heap allocator. If the heap allocator is used, this won't even be visible to the OS, as it will be handled within your C library.

也许您将磁盘上文件的大小与FILE的大小混淆了. FILE不是磁盘上的文件,它是C typedef struct,它是对该文件的缓冲I/O的控制结构,并将包括(例如)文件描述符.该文件没有(通常)完全加载到RAM中.它的一小部分(缓冲区)被装入,并且POSIX标准规定缓冲区的长度应为BUFSIZ.请参阅: http://pubs.opengroup.org/onlinepubs/009695399/basedefs /stdio.h.html

Perhaps you are confusing the size of the file on disk with the size of FILE. FILE is not the file on disk, it is a C typedef struct which is a control structure for the buffered I/O to that file, and will include (e.g.) the file descriptor. The file isn't (normally) loaded into RAM completely. A small section of it (the buffer) is loaded in, and the POSIX standard says that buffer shall be BUFSIZ in length. See: http://pubs.opengroup.org/onlinepubs/009695399/basedefs/stdio.h.html

这篇关于调用fopen时的内存分配不明确的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆