Is there a way to mark a chunk of allocated memory readonly?

if I allocate some memory using malloc() is there a way to mark it readonly. So memcpy() fails if someone attempt to write to it?

This is connected to a faulty api design where users are miss-using a const pointer returned by a method GetValue() which is part of large memory structure. Since we want to avoid copying of large chunk of memory we return live pointer within a structured memory which is of a specific format. Now problem is that some user find hack to get there stuff working by writing to this memory directly and avoid SetValue() call that does allocation and properly handing in memory binary format that we have developed. Although there hack sometime work but sometime it causes memory access violation due to incorrect interpretation of control flags which has been overridden by user.

Educating user is one task but let say for now we want there code to fail.

I am just wondering if we can simply protect against this case.

For analogy assume someone get a blob column from sqlite statement and then write back to it. Although in case of sqlite it will not make sense but this somewhat happing in our case.

On most hardware architectures you can only change protection attributes on entire memory pages; you can't mark a fragment of a page read-only.

The relevant APIs are:

• mprotect() on Unix;
• VirtualProtect() on Windows.

You'll need to ensure that the memory page doesn't contain anything that you don't want to make read-only. To do this, you'll either have to overallocate with malloc(), or use a different allocation API, such as mmap(), posix_memalign() or VirtualAlloc().

Depends on the platform. On Linux, you could use mprotect() (http://linux.die.net/man/2/mprotect).

On Windows you might try VirtualProtect() (http://msdn.microsoft.com/en-us/library/windows/desktop/aa366898(v=vs.85).aspx). I've never used it though.

Edit: This is not a duplicate of NPE's answer. NPE originally had a different answer; it was edited later and mprotect() and VirtualProtect() were added.

> a faulty api design where users are miss-using a const pointer returned by a method GetValue() which is part of large memory structure. Since we want to avoid copying of large chunk of memory we return live pointer within a structured memory which is of a specific format

That is not clearly a faulty API design. An API is a contract: you promise your class will behave in a particular way, clients of the class promise to use the API in the proper manner. Dirty tricks like const_cast are improper (and in some, but not all cases, have undefined behaviour).

It would be faulty API design if using const_cast lead to a security issue. In that case you must copy the chunk of memory, or redesign the API. This is the norm in Java, which does not have the equivalent of const (despite const being a reserved word in Java).

Obsfucate the pointer. i.e. return to the client the pointer plus an offset, now they can't use the pointer directly. whenever the pointer is passed to your code via the official API, subtract the offset and use the pointer as usual.