I don't know if this makes sense in general, e.g. can we really guarantee that we will never have to take a lock on the buffer in future ? (taking a lock would modify the structure data, so would not really be const).

It should be obvious to anyone from the name already that this does not "modify" the buffer, so I don't really see the point of doing this either.

(In reply to comment #1)

I'm of course OK waiting for agreement on this one but unless
my English is wrong here, your two paragraphs are contradictory.
If it's obvious that these funcs won't modify the buffer then
we can and should guarantee (and enforce) this behavior. Using
const * seems like a correct way forward to ensure both.

There's a strict sense of modifying the buffer (which the compiler might care about) , and a less strict sense (which the user might care about). Both are not necessarily the same.

For example: we might want cache the size in future. This might involve writes to the buffer struct in get_size(), but the user might not care about that because it doesn't touch anything visible to her.

I see but, wouldn't it make more sense to cache the
size only on functions that are actually meant to modify
the buffer's mem and are then expected to modify the
buffer size (if needed) in both the strict and non-strict
senses you mention? The idea of writing to anything on
a get_size() func keeps sounding wrong to me, API-wise
that is.

I must confess that I am missing a few implementation
details here (taking a look now) so sry if what I'm
saying or my understanding of what you meant is wrong.

We have had problems in the past with using const for refcounted objects. In general, const works for simple structs and types but not so for objects.

Agreed, let's not do this then. We can do that once we upgrade to C++ and can use the mutable keyword in combination with const ;)