«

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

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
lid

In article < .com>,
<> 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??

> > 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

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.

--

In article <. com>,
<> 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

>> > 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

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

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.

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
lid