is byte allocated

Discussion in 'C Programming' started by sinbad, Dec 21, 2008.

  1. sinbad

    sinbad Guest

    hi,
    Is there any way to know if a byte of memory is allocated.
    Does C allows me to write such a function, or Is there any other way
    for
    doing this. btw i am using gcc in linux; Here, the byte may not be
    allocated
    to this process but might be used by another process, even in that
    case
    i should get the result as alloced; Conversely is there a way to tell
    malloc ()
    that i need memory to be allocated at this memory location if
    possible?

    int main ()
    {
    if (is_alloced(0x3434453E))
    do_something;
    else
    do_something_else;
    return 0;
    }
     
    sinbad, Dec 21, 2008
    #1
    1. Advertising

  2. sinbad <> writes:
    > hi, Is there any way to know if a byte of memory is allocated. Does C
    > allows me to write such a function, or Is there any other way for
    > doing this. btw i am using gcc in linux; Here, the byte may not be
    > allocated to this process but might be used by another process, even
    > in that case i should get the result as alloced; Conversely is there a
    > way to tell malloc () that i need memory to be allocated at this
    > memory location if possible?


    By "allocated", I presume you mean allocated by malloc (or calloc, or
    realloc).

    The answer to both your questions is no. At least, there's no
    portable way to do what you're asking. (I don't know of any
    non-portable way either.)

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Dec 21, 2008
    #2
    1. Advertising

  3. On Dec 21, 10:56 pm, Keith Thompson <> wrote:

    > By "allocated", I presume you mean allocated by malloc (or calloc, or
    > realloc).
    >
    > The answer to both your questions is no.  At least, there's no
    > portable way to do what you're asking.  (I don't know of any
    > non-portable way either.)



    One solution would be to create a wrapper for malloc that contains
    info about allocations, maybe something like as follows:

    #include <stdint.h>

    typedef struct AllocInfo {
    char unsigned const *pfirst;
    char unsigned const *pend;
    } AllocInfo;

    AllocInfo allocs[50];

    uint_fast8_t IsAddressAllocated(void const *const addr)
    {
    AllocInfo const *p = allocs;

    while (p++->p_first) /* Array is null-terminated */
    {
    if ( (char unsigned const*)addr >= p->pfirst
    && (char unsigned const*)addr < p->pend
    )
    return 1;
    }

    return 0;
    }

    Actually I just realised that the behaviour of those comparisons is
    undefined because they don't (necessarily) refer to the same object.
    It could be rewritten to take only the starting address of the
    allocation into account.

    Anyway, then you'd wrap malloc:

    #include <stddef.h>

    void *mymalloc(size_t const val)
    {
    static AllocInfo const *p = allocs;

    if (p == (allocs + (sizeof allocs / sizeof *allocs) -1) )
    return 0;

    p->pfirst = malloc(val);

    if (!p->pfirst)
    return 0;
    else
    {
    p->pend = p->pfirst + val;

    return (p++)->pfirst;
    }
    }

    Then you could call "mymalloc" instead of "malloc", which can be
    achieved quite easily with a "Find and Replace in Files", or perhaps
    you might be bold enough to edit your "stdlib.h" file to:

    #define malloc mymalloc

    By the way, have you ever heard of mudflap? It's a memory access
    debugging tool built into the GCC compiler. It commandeers the
    compiler's memory access routines; for instance instead of having the
    normal dereference operator, it calls a function that checks the
    validity of the operation. It's pretty cool.
     
    Tomás Ó hÉilidhe, Dec 21, 2008
    #3
  4. In article <>,
    Gordon Burditt <> wrote:
    ....
    >Unless you are dealing with shared memory segments, there is no way
    >to form a pointer that points at memory in another process on a
    >UNIX-like system. Each process has its own address space. Even


    Not true. DOS is "Unix-like" and it is easy there for one process to
    point at and access memory in another process.

    In the above, the word "process" should be read to include "TSR"
    processes.
     
    Kenny McCormack, Dec 22, 2008
    #4
  5. sinbad

    sinbad Guest

    the os on which the process is running should be able to provide
    such system call. since memory is managed by os, It should definitely
    be able to tell if a byte is already in use or ready to use
    (unalloced);

    offtopic: Does linux provides anything of this sort;

    thanks
     
    sinbad, Dec 22, 2008
    #5
  6. sinbad

    Flash Gordon Guest

    sinbad wrote, On 22/12/08 03:53:
    > the os on which the process is running should be able to provide
    > such system call. since memory is managed by os,


    Not on all Operating Systems and not all the time.

    > It should definitely
    > be able to tell if a byte is already in use or ready to use
    > (unalloced);


    Just because it is freed by a program does not mean it is returned to
    the OS. Just because it is allocated by the OS does not mean it is
    available for normal use (it might be in use as part of a control
    structure used by the C library for managing a heap).

    > offtopic: Does linux provides anything of this sort;


    As you know it is off topic try asking where it is topical instead.
    --
    Flash Gordon
    If spamming me sent it to
    If emailing me use my reply-to address
    See the comp.lang.c Wiki hosted by me at http://clc-wiki.net/
     
    Flash Gordon, Dec 22, 2008
    #6
  7. sinbad

    CBFalconer Guest

    Gordon Burditt wrote:
    >
    >>> Unless you are dealing with shared memory segments, there is no
    >>> way to form a pointer that points at memory in another process
    >>> on a UNIX-like system. Each process has its own address space.

    >>
    >> Not true. DOS is "Unix-like"

    >
    > I don't agree with this at all. You don't have multiple processes
    > on MS-DOS. You don't have the possibility of multiple users.
    > There is no implementation of fork(). There are no user ids or
    > file ownership.
    >
    >> and it is easy there for one process to
    >> point at and access memory in another process.

    >
    > DOS doesn't support multiple processes.
    >
    >> In the above, the word "process" should be read to include "TSR"
    >> processes.

    >
    > A TSR is not a process, it's a function or several that gets a
    > callback. Some TSRs might qualify as device drivers.


    I guess you weren't around in the old days, when there were
    multiple methods of turning MSDOS into a multi-tasking system.
    They usually included a TSR that detected all DOS calls and
    inhibited interrupts. The quality of the result was a great
    variable. Being too young is not a crime.

    Since you have deleted all attributions, we have no idea who you
    are agreeing or disagreeing with. You are also quoting them
    without proper identification of the authors.

    --
    [mail]: Chuck F (cbfalconer at maineline dot net)
    [page]: <http://cbfalconer.home.att.net>
    Try the download section.
     
    CBFalconer, Dec 22, 2008
    #7
  8. sinbad

    Ian Collins Guest

    CBFalconer wrote:
    > Gordon Burditt wrote:
    >>>> Unless you are dealing with shared memory segments, there is no
    >>>> way to form a pointer that points at memory in another process
    >>>> on a UNIX-like system. Each process has its own address space.
    >>> Not true. DOS is "Unix-like"

    >> I don't agree with this at all. You don't have multiple processes
    >> on MS-DOS. You don't have the possibility of multiple users.
    >> There is no implementation of fork(). There are no user ids or
    >> file ownership.
    >>
    >>> and it is easy there for one process to
    >>> point at and access memory in another process.

    >> DOS doesn't support multiple processes.
    >>
    >>> In the above, the word "process" should be read to include "TSR"
    >>> processes.

    >> A TSR is not a process, it's a function or several that gets a
    >> callback. Some TSRs might qualify as device drivers.

    >
    > I guess you weren't around in the old days, when there were
    > multiple methods of turning MSDOS into a multi-tasking system.
    > They usually included a TSR that detected all DOS calls and
    > inhibited interrupts. The quality of the result was a great
    > variable. Being too young is not a crime.
    >

    Old days? The last multi-tasking implementation I wrote on DOS was in 1993!

    > Since you have deleted all attributions, we have no idea who you
    > are agreeing or disagreeing with. You are also quoting them
    > without proper identification of the authors.


    He's an arrogant prat who thinks he's above Usenet conventions.

    --
    Ian Collins
     
    Ian Collins, Dec 22, 2008
    #8
    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. Andreas
    Replies:
    1
    Views:
    855
    Jonathan Bromley
    May 4, 2004
  2. Bharat Bhushan

    Appending byte[] to another byte[] array

    Bharat Bhushan, Aug 5, 2003, in forum: Java
    Replies:
    15
    Views:
    40,257
    Roedy Green
    Aug 5, 2003
  3. Jean-Daniel Gamache
    Replies:
    0
    Views:
    425
    Jean-Daniel Gamache
    Jul 14, 2004
  4. Replies:
    5
    Views:
    623
    Matt Wharton
    Dec 9, 2004
  5. rlc
    Replies:
    10
    Views:
    1,140
    David Thompson
    Jul 1, 2009
Loading...

Share This Page