MemoryBuffer and its requirement for NULL termination

MemoryBuffer requires that its buffer be NULL terminated. This is handy for some users, but it is a hard requirement for some cases. For example, currently I get the following valgrind error when doing LTO and fetching an archive member:

at 0x6DAC36E: llvm::MemoryBuffer::init(char const*, char const*) (MemoryBuffer.cpp:50)

Address 0x5fecea0 is 0 bytes after a block of size 464 alloc'd

  claim_file_hook(ld_plugin_input_file const*, int*) (gold-plugin.cpp:261)

The memory access is the assert that the buffer is null terminated and the allocation is done to read in an archive member to pass to libLTO.

I could fix this by just allocating one byte more, but I would like instead to mmap the archives. There is no way to get a NULL terminated map in the middle of a file.

I propose we split MemoryBuffer in two classes. The base one would not guarantee that the buffer is null terminated. A class that does guarantee null termination can then be implemented by inheriting from it.

Using two classes has the advantaged that the requirement for null termination shows up in the type signature.

Now, what should the default be? My preference would be to use the name MemoryBuffer for a class that doesn't guarantee null termination and have a ZMemoryBuffer that does. If it is really common to depend on the null termination, we can keep MemoryBuffer with its current meaning and call the base class NZMemoryBuffer or something.

Better names suggestions are welcome :slight_smile:

Cheers,
Rafael