How to set memory properties

[Markus.Elfring]

Some APIs/SDKs are available to modify settings like "readable",
"writeable" or "executeable".
Examples:
-
http://msdn.microsoft.com/library/en..._constants.asp
- http://www.opengroup.org/onlinepubs/.../mprotect.html
- http://en.wikipedia.org/wiki/PaX

Would a companion function fit to the "realloc" programming interface
to
change such properties?
Is the management of such flags a part of the standard C library
already?
http://en.wikipedia.org/wiki/Malloc

I imagine to implement memory areas that are updated to be "read-only"
after an initial assignment.

Regards,
Markus

[Eric Sosman]

Ma************@web.de wrote:

Some APIs/SDKs are available to modify settings like "readable",
"writeable" or "executeable".
Examples:
-
http://msdn.microsoft.com/library/en..._constants.asp
- http://www.opengroup.org/onlinepubs/.../mprotect.html
- http://en.wikipedia.org/wiki/PaX

Would a companion function fit to the "realloc" programming interface
to
change such properties?
A design might be worked out.
Is the management of such flags a part of the standard C library
already?
http://en.wikipedia.org/wiki/Malloc
No. The Standard recognizes the possibility that some
memory may be read-only, but does not require the capability
and provides no way to control it. Fancier attributes like
"okay to forget the content" or "likely to be used sequentially"
are not even dreamt of; they fall under the general heading of
platform-specific optimizations.
I imagine to implement memory areas that are updated to be "read-only"
after an initial assignment.

Most actual implementations handle attributes at a "memory
page" level, which could make it difficult to apply arbitrary
attributes to already-acquired memory: what if they conflict
with the attributes of other regions already allocated from the
same page? I think you'd need either a "copy this data somewhere
else and give it these attributes" interface, or else an "allocate
some memory whose attributes I can later change without blowing
up the Universe" sort of thing. The latter might be preferable
if you contemplate an "executable" attribute and cannot generate
position-independent code.

--
Eric Sosman
es*****@acm-dot-org.invalid

[Walter Roberson]

In article <11**********************@g49g2000cwa.googlegroups .com>,
<Ma************@web.de> wrote:
:Some APIs/SDKs are available to modify settings like "readable",
:"writeable" or "executeable".

:Is the management of such flags a part of the standard C library
:already?

No.

:I imagine to implement memory areas that are updated to be "read-only"
:after an initial assignment.

I seem to recall hearing of such a property in C++, but not in
C -- at least not in C89. The 'const' attribute in C is handled at
the compiler level, not the OS level.

Generally speaking, the C standard disavows all knowledge of the
OS facilities beyond the existance of the narrowly-defined
file I/O operators. C does not require that memory protection
exists on the system at all.
--
Would you buy a used bit from this man??

[Markus.Elfring]

> > Is the management of such flags a part of the standard

C library already?
http://en.wikipedia.org/wiki/Malloc

No. The Standard recognizes the possibility that some
memory may be read-only, but does not require the capability
and provides no way to control it. Fancier attributes like
"okay to forget the content" or "likely to be used sequentially"
are not even dreamt of; they fall under the general heading of
platform-specific optimizations.

Are there any chances that this kind of functionality can be added to
the standard API?

Regards,
Markus

[Walter Roberson]

In article <11*********************@g14g2000cwa.googlegroups. com>,
<Ma************@web.de> wrote:

> Is the management of such flags a part of the standard
> C library already?

No. The Standard recognizes the possibility that some
memory may be read-only, but does not require the capability
and provides no way to control it.

Are there any chances that this kind of functionality can be added to
the standard API?

Certainly. If you would like to see such functionality in the standard
API, all you have to do is help a large number of people "reclaim" or
"invest" their millions of dollars, then take the resulting funds and
bribe every single member of the ANSI committees who has voting rights
on the proposition.

Other than that... well, unless through corruption or business politics,
it seems more than a little unlikely to happen any time soon.
ANSI/ISO usually take fair efforts to avoid locking in any behaviour
that is not readily implemented on most machines, including those
that do not HAVE any kinds of memory protection or virtual memory.

Maybe somewhere around C57 (approved in 2059, widely available about
2072).
--
Entropy is the logarithm of probability -- Boltzmann

[Eric Sosman]

Ma************@web.de wrote:

Is the management of such flags a part of the standard
C library already?
http://en.wikipedia.org/wiki/Malloc

No. The Standard recognizes the possibility that some
memory may be read-only, but does not require the capability
and provides no way to control it. Fancier attributes like
"okay to forget the content" or "likely to be used sequentially"
are not even dreamt of; they fall under the general heading of
platform-specific optimizations.

Are there any chances that this kind of functionality can be added to
the standard API?

The question might be better suited to comp.std.c than
to this newsgroup.

The committee that writes and revises the Standard seems
to look more favorably on "prior art" than on paper arguments
about a feature's usefulness. That is, a real implementation
seems to carry more weight than an "I'd like" plea, especially
if you can get lots of people to use the implementation and
tell the committee how much they like it.

--
Er*********@sun.com

[Gordon Burditt]

>> > Is the management of such flags a part of the standard

> C library already?
> http://en.wikipedia.org/wiki/Malloc

No. The Standard recognizes the possibility that some
memory may be read-only, but does not require the capability
and provides no way to control it. Fancier attributes like
"okay to forget the content" or "likely to be used sequentially"
are not even dreamt of; they fall under the general heading of
platform-specific optimizations.

Are there any chances that this kind of functionality can be added to
the standard API?

About the only way to make this kind of functionality *USABLE* is to
provide a method of allocating memory which does not share a memory
page with any other allocated memory, where "memory page" is defined
as the minimum granularity for which attributes like "writable" and
"executable" can act. For i386 architecture, that is 4K bytes (or
sometimes 4M bytes) at the hardware level. Otherwise, when you
change the attributes of one piece of memory, you may alter the
attributes of others unexpectedly, and that makes use of the features
so unpredictable that they are useless.

Another possible approach would be to define "pools" of memory.
Any memory in a "pool" has the same attributes as other memory in
the same "pool", so you change the attributes of everything in a
pool all at once. Internally, no pool would share memory pages
with another pool. Then you allocate memory out of specific pools
with a new function like malloc() that takes a pool as a second
argument. This is perhaps not quite so wasteful as putting every
allocation in its own page.

Gordon L. Burditt

[CBFalconer]

Eric Sosman wrote:

.... snip ...
The committee that writes and revises the Standard seems
to look more favorably on "prior art" than on paper arguments
about a feature's usefulness. That is, a real implementation
seems to carry more weight than an "I'd like" plea, especially
if you can get lots of people to use the implementation and
tell the committee how much they like it.

Which I consider to be right and proper. Without it the standards
would have all the ephermeral solidity of Microsoft systems, or
long term damage would be done similar to what Borland did to
Pascal. If anything they have gone too far in kowtowing to "I'd
like" and the result is features that are hard to implement and
integrate into the existing systems.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson

[SM Ryan]

Ma************@web.de wrote:
# Some APIs/SDKs are available to modify settings like "readable",
# "writeable" or "executeable".

Those kinds of things are usually apply to an entire memory page.

# Would a companion function fit to the "realloc" programming interface

malloc et al are not required to be page oriented. (Some are internally
page oriented, but that is not exposed across the interface.)

You can make a new kind of allocator that is page boundary aware,
but I think trying to shoehorn it into the realloc interface would
seem more trouble than it would be worth.

--
SM Ryan http://www.rawbw.com/~wyrmwif/
There are subtler ways of badgering a witness.

[Eric Sosman]

CBFalconer wrote:

Eric Sosman wrote:

... snip ...

The committee that writes and revises the Standard seems
to look more favorably on "prior art" than on paper arguments
about a feature's usefulness. That is, a real implementation
seems to carry more weight than an "I'd like" plea, especially
if you can get lots of people to use the implementation and
tell the committee how much they like it.

Which I consider to be right and proper. Without it the standards
would have all the ephermeral solidity of Microsoft systems, or
long term damage would be done similar to what Borland did to
Pascal. If anything they have gone too far in kowtowing to "I'd
like" and the result is features that are hard to implement and
integrate into the existing systems.

Aha! I see you've experienced PL/I ;-)

--
Eric Sosman
es*****@acm-dot-org.invalid

[Dave Thompson]

On Thu, 14 Jul 2005 14:29:35 +0000 (UTC), ro******@ibd.nrc-cnrc.gc.ca
(Walter Roberson) wrote:

In article <11**********************@g49g2000cwa.googlegroups .com>,
<Ma************@web.de> wrote: <snip> :I imagine to implement memory areas that are updated to be "read-only"
:after an initial assignment.

I seem to recall hearing of such a property in C++, but not in
C -- at least not in C89. The 'const' attribute in C is handled at
the compiler level, not the OS level.
No more in C++ than C. There are two other things you (or anyone else)
might have confused with this:

In C++ as in C you have const-qualified objects, and members of a
struct (in C++ also class), which can be initialized in the defining
declaration (of an instance) but not assigned to thereafter. If a
struct or class instance is const this means you can't assign to it or
to any member of it -- const 'distributes'. In C++ you can declare a
member 'mutable' which means that it can be assigned even in an
instance that is const or is 'promoted' to const; this is intended to
be used for 'hidden' (at least protected) data which is used within
the class's methods but does not affect the OO-ish state, such as
memoization/cache, hidden resources, debugging, etc.

C++ allows definitions of class instances (const or not) to specify
initial values that imply running a (particular) constructor rather
than just storing a value or list of values. This includes
static-duration objects, which in C (and in C++ for C-like 'POD'
types) can be and normally are 'initialized' at compile/link time. To
allow this C++ breaks initialization of statics into two pieces --
'static initialization' which has the same capabilities as C (zeros,
fixed values, addresses of other static objects) and is normally done
in the executable file, and 'dynamic initialization' which can be and
usually is done by running the constructor at runtime, after process
startup but before the object is used. An implementation thus _might_
reasonably put const-qualified static objects in a memory area that is
writable while it does the dynamic initialization and is then made
unwritable. (But I don't know of any that actually do.)
Generally speaking, the C standard disavows all knowledge of the
OS facilities beyond the existance of the narrowly-defined
file I/O operators. C does not require that memory protection
exists on the system at all.

And optionally ability to execute commands (of some sort); and real
(wall) and CPU clocks. And (things that might map to) signals.

And in C99 with optional 60559, certain controls and inquiries on FPU
settings, which might involve OS or might just go to hardware.

- David.Thompson1 at worldnet.att.net