[LLVMdev] MemoryBuffer

[OvermindDL1]

I was writing something using MemoryBuffer, and while looking through
its code I came across line 59:
  assert(BufEnd[0] == 0 && "Buffer is not null terminated!");
I am curious if the MemoryBuffer only supports non-binary, non-null
embedded files, or if it supports binary as well.  I do not see
anything inherently not expecting binary files except for that one
line, so I am curious as to the purpose of that assert?

Also, is the BufferEnd parameter supposed to be a pointer to the end
of the input, or to one past the end as in the STL?  It seems it is
supposed to be to the end of the input since that assert could access
invalid memory if it was to one past the end, but if it was to the end
of input and not one past the end that that seems inconsistent, so I
am curious as to which it is?  I know the comments in the header
indicate that the end needs to be dereferencable for getMemBuffer, but
not for getMemBufferCopy and other ones, so I am curious as to why it
is inconsistent?  I do not see any real reason why getMemBuffer has
the requirement that the EndPtr needs to be dereferencable except for
that assert, and I do not really see a reason for that assert right
off the bat.  Basically, is there a rational section somewhere for the
design of MemoryBuffer?

Although the public member function getBufferEnd has no comments, from
the looks of it, I think it returns one past the end based on how
getBufferSize is implemented.  Out of curiosity, since const char*
fulfills the concept of a randomIterator concept, would there be any
aversion to add an stl style begin/end that returns the same things?
I have some template code I use (and do not control) that can take an
STL style container (only in that it calls begin/end on it), and I see
no real reason as to why MemoryBuffer could not implement an STL style
begin/end iterator interface by just returning const char*.  This
would allow it to fulfill a few other concepts as well.  Perhaps even
giving it a more complete interface as well, would not change
functionality, but would add capability.  Would anyone be opposed to a
patch?