How to set memory properties

Discussion in 'C Programming' started by Markus.Elfring@web.de, Jul 14, 2005.

  1. Guest

    Some APIs/SDKs are available to modify settings like "readable",
    "writeable" or "executeable".
    Examples:
    -
    http://msdn.microsoft.com/library/en-us/memory/base/memory_protection_constants.asp
    - http://www.opengroup.org/onlinepubs/009695399/functions/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
    , Jul 14, 2005
    #1
    1. Advertising

  2. Eric Sosman Guest

    wrote:
    > Some APIs/SDKs are available to modify settings like "readable",
    > "writeable" or "executeable".
    > Examples:
    > -
    > http://msdn.microsoft.com/library/en-us/memory/base/memory_protection_constants.asp
    > - http://www.opengroup.org/onlinepubs/009695399/functions/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
    Eric Sosman, Jul 14, 2005
    #2
    1. Advertising

  3. In article <>,
    <> 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??
    Walter Roberson, Jul 14, 2005
    #3
  4. Guest

    > > 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
    , Jul 14, 2005
    #4
  5. Eric Sosman Guest

    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.

    --
    Eric Sosman, Jul 14, 2005
    #5
  6. In article <>,
    <> 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
    Walter Roberson, Jul 14, 2005
    #6
  7. >> > 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
    Gordon Burditt, Jul 14, 2005
    #7
  8. CBFalconer Guest

    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
    CBFalconer, Jul 14, 2005
    #8
  9. SM Ryan Guest

    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.
    SM Ryan, Jul 14, 2005
    #9
  10. Eric Sosman Guest

    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
    Eric Sosman, Jul 15, 2005
    #10
  11. On Thu, 14 Jul 2005 14:29:35 +0000 (UTC), -cnrc.gc.ca
    (Walter Roberson) wrote:

    > In article <>,
    > <> 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
    Dave Thompson, Jul 25, 2005
    #11
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Nathan Sokalski
    Replies:
    0
    Views:
    906
    Nathan Sokalski
    Oct 17, 2005
  2. =?Utf-8?B?Q2hyaXN0b3BoZSBQZWlsbGV0?=

    CompositeControls: ViewState properties w/ Mapped properties probl

    =?Utf-8?B?Q2hyaXN0b3BoZSBQZWlsbGV0?=, Jan 19, 2006, in forum: ASP .Net
    Replies:
    1
    Views:
    1,137
    Steven Cheng[MSFT]
    Jan 19, 2006
  3. Kent Lichty
    Replies:
    0
    Views:
    832
    Kent Lichty
    Apr 16, 2004
  4. Victor Porton
    Replies:
    1
    Views:
    697
    Steven T. Hatton
    Aug 29, 2004
  5. Wardie
    Replies:
    4
    Views:
    488
    Wardie
    Nov 8, 2006
Loading...

Share This Page