c++ - 如何找到 `FILE*`的相对地址

Question

要了解我为什么要做下面描述的事情，您可以阅读 this题。简而言之:由于某种原因，库代码请求了一个未由相应类定义的函数，我的解决方案:通过我的自定义类扩展类，编写请求的函数并使用我的类。

我有一个函数 void* advance(uint64_t nbytes) 会被一些库代码调用为 memcpy(object.advance(nbytes), source, nbytes)。从 advance() 内部，我可以访问一个 FILE* 应该存储结果的地方，所以据我所知，我必须返回一个指针，该指针将具有相对地址到整个内存，但在 FILE* 中，以便库代码可以适本地编写。

到目前为止我已经尝试过:

void* advance(uint64_t nbytes){
    return this->getFilePointer()->_IO_buf_base;
}

void* advance(uint64_t nbytes){
    return this->getFilePointer()->_IO_write_base;
}

由于我不熟悉文件内存分配的一般工作原理，我认为从技术上讲它也应该分配，因此我这样做了:

void* advance(uint64_t nbytes){
    char *ptr = new char [nbytes];
    fwrite(ptr,1,nbytes,this->getFilePointer());
    return this->getFilePointer()->_IO_write_base;
}

我在上一个示例中意识到，出于某种原因 this->getFilePointer()->_IO_write_ptr - this->getFilePointer()->_IO_write_base == 125 而 nbytes == 9830525，显然又出问题了...

以上所有示例都会触发段错误。

我的逻辑是否正确，即我正在做的事情是否有意义？如果是，我怎样才能获得正确的结果？

附注我尽量让问题尽可能简短，如果需要任何其他信息，我会提供。

编辑:

这是调用advance()的代码

void Bag::readMessageDataIntoStream(IndexEntry const& index_entry, Stream& stream) const {
    ros::Header header;
    uint32_t data_size;
    uint32_t bytes_read;
    switch (version_)
    {
    case 200:
    {
        decompressChunk(index_entry.chunk_pos);
        readMessageDataHeaderFromBuffer(*current_buffer_, index_entry.offset, header, data_size, bytes_read);
        if (data_size > 0)
            memcpy(stream.advance(data_size), current_buffer_->getData() + index_entry.offset + bytes_read, data_size);
        break;
    }
    case 102:
    {
        readMessageDataRecord102(index_entry.chunk_pos, header);
        data_size = record_buffer_.getSize();
        if (data_size > 0)
            memcpy(stream.advance(data_size), record_buffer_.getData(), data_size);
        break;
    }
    default:
        throw BagFormatException((boost::format("Unhandled version: %1%") % version_).str());
    }
}

Stream 是我的对象，它将继承自 this一个

我也试过这个:

char *ptr;
void* advance(uint64_t nbytes){
        ptr = new char [nbytes];
        return ptr;
}

它显然有效，但这不是我试图实现的，因为在这种情况下我将不得不自己解析数据，我试图避免这种情况。

Answer 1

您的逻辑不正确，因为它打破了因果关系。

前两次尝试只是尝试覆盖某些文件的内部数据，仅此而已。他们不会也不会触发写入。下一个在复制数据之前写入数据，然后尝试覆盖一些不相关的文件的内部数据(当然会出现段错误/GPF)。

关键问题是首先调用您的函数，然后才复制数据 (memcpy)。 memcpy 不会自行触发文件写入。

您可以尝试以下方法:

第一次调用 advance() 只是分配一个缓冲区。接下来的每个调用首先尝试将缓冲区(在上一个 advance() 调用之后立即填充)写入文件，然后为下一个缓冲区分配数据。最后，对象的析构函数(或者如果可以的话，在整个复制操作之后调用的某个方法)从上次调用分配的缓冲区中写入数据，然后(可选)关闭文件。 IE。类似于以下内容:

class AutoWrite {
 public:
  AutoWrite(FILE* file): file_(file), buffer_(nullptr), size_(0) {}

  ~AutoWrite() {
    flush_last();
    fclose(file_);
  }

  void* advance(uint64_t nbytes) {
    flush_last();
    buffer_ = new char[nbytes];
    size_ = nbytes;
    return buffer;
  }

  void flush_last() {
    if (size_ > 0) {
      fwrite(static_cast<void*>(buffer_), 1, size_, file);
      size_ = 0;
      delete[] buffer_;
    }
  }

 private:
  FILE* file_;
  char* buffer_;
  uint64_t size_;
};

这个东西有一个“特性”:数据不会立即保存，而是仅在分配下一个缓冲区之前(或在对象销毁期间)直接写入磁盘。

附言。不要弄乱 FILE 内部结构。这是个坏主意。它不仅不可移植，而且可能会因任何随机编译器或标准库更新而中断。而且它不能解决您的问题。